Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area

Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:


No, the original crash being discussed was a GP fault in head_64.S as
it tries
to initialize the kernel segments. The cause was that the prototype
GDT is all
zero, even though it's an initialized variable, and inspection of
vmlinux shows
that it has the right contents. But somehow it's either 1) getting
zeroed on
load, or 2) is loaded to the wrong place.

The zero-based PDA mechanism requires the introduction of a new ELF
segment
based at vaddr 0 which is sufficiently unusual that it wouldn't
surprise me if
its triggering some toolchain bug.


Agreed. Given the previous description my hunch is that the bug is
occurring
during objcopy. If vmlinux is good and the compressed kernel is bad.

It should be possible to look at vmlinux.bin and see if that was
generated
properly.


Mike: what would happen if the PDA were based at 4k rather than 0?
The stack
canary would still be at its small offset (0x20?), but it doesn't
need to be
initialized. I'm not sure if doing so would fix anything, however.


I'm dense today. Why are we doing a zero based pda? That seems the most
likely culprit of linker trouble, and we should be able to put a smaller
offset in the segment register to allow for everything to work as
expected.


The only reason we need to do a zero-based PDA is because of the
boneheaded gcc/x86_64 ABI decision to put the stack canary at a fixed
offset from %gs (all they had to do was define it as a weak symbol we
could override). If we want to support stack-protector and unify the
handling of per-cpu variables, we need to rebase the per-cpu area at
zero, starting with the PDA.

My own inclination would be to drop stack-protector support until gcc
gets fixed, rather than letting it prevent us from unifying an area
which is in need of unification...

J

I might be inclined to agree except most of the past few months of
finding problems caused by NR_CPUS=4096 has been stack overflow. So
any help detecting this condition is very useful. I can get static
stacksizes (of course), but there's not a lot of help determining
call chains except via actually executing the code.

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Storage of Variables
    ... code at entry to a function zero out the stack. ... In C, there is really no such concept as a heap, though you could ... the bss segment. ... And to initialize the data segment, ...
    (comp.os.linux.misc)
  • Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area
    ... to initialize the kernel segments. ... The zero-based PDA mechanism requires the introduction of a new ELF segment ... If we want to support stack-protector and unify the handling of per-cpu variables, we need to rebase the per-cpu area at zero, starting with the PDA. ...
    (Linux-Kernel)
  • Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area
    ... to initialize the kernel segments. ... The zero-based PDA mechanism requires the introduction of a new ELF segment ... Why are we doing a zero based pda? ...
    (Linux-Kernel)
  • Re: Ive got a lot of beginner questions :(
    ... It would go into .bss. ... C guarantees that abc will be initialized to all zero bytes. ... go ahead and put all global storage in a data-like segment (in fact, ... The variables that C does *not* initialize are automatic (stack ...
    (comp.lang.asm.x86)
  • Re: Problem only in release version!
    ... not executed in Release mode (I believe, but I also thought Debug ... initialized variables to zero, ... The Release version will not initialize anything 'naturally' ... >>the contents of the memory addresses they happen to get assigned to). ...
    (microsoft.public.dotnet.languages.vc)