BRSGP relocation truncations in linking kernel for Alpha.

BRSGP relocation truncations in linking kernel for Alpha.

[Michael Cree]

When building recent kernels for Alpha I am getting the following
relocation errors:

alpha-linux-gnu-ld -static -N --build-id -o .tmp_vmlinux1 -T
./arch/alpha/kernel/vmlinux.lds arch/alpha/kernel/head.o init/built-in.o
--start-group usr/built-in.o arch/alpha/kernel/built-in.o
arch/alpha/mm/built-in.o arch/alpha/math-emu/built-in.o
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o
lib/lib.a arch/alpha/lib/lib.a lib/built-in.o arch/alpha/lib/built-in.o
drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o
virt/built-in.o --end-group
net/built-in.o: In function `packet_setsockopt':
net/packet/af_packet.o:(.text+0xf71d0): relocation truncated to fit:
BRSGP against symbol `__copy_user' defined in .text section in
arch/alpha/lib/lib.a(ev6-copy_user.o)

I can solve it by de-selecting config items, but it is getting
frustrating that I can't build the kernel I would like to build.

Is there anything we can do to resolve these relocations?

Cheers
Michael.

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Helge Deller]

Hi Michael,

On 22.10.2016 04:41, Michael Cree wrote:
> When building recent kernels for Alpha I am getting the following
> relocation errors:
> 
> alpha-linux-gnu-ld -static -N --build-id -o .tmp_vmlinux1 -T
> ./arch/alpha/kernel/vmlinux.lds arch/alpha/kernel/head.o init/built-in.o
> --start-group usr/built-in.o arch/alpha/kernel/built-in.o
> arch/alpha/mm/built-in.o arch/alpha/math-emu/built-in.o
> kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
> ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o
> lib/lib.a arch/alpha/lib/lib.a lib/built-in.o arch/alpha/lib/built-in.o
> drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o
> virt/built-in.o --end-group
> net/built-in.o: In function `packet_setsockopt':
> net/packet/af_packet.o:(.text+0xf71d0): relocation truncated to fit:
> BRSGP against symbol `__copy_user' defined in .text section in
> arch/alpha/lib/lib.a(ev6-copy_user.o)
> 
> I can solve it by de-selecting config items, but it is getting
> frustrating that I can't build the kernel I would like to build.
> 
> Is there anything we can do to resolve these relocations?

You could try to play around where various functions get located
in the final vmlinux file. For that you need to modify 
arch/alpha/kernel/vmlinux.lds.S.
I did quite such optimizations for parisc like that.

Does it only happens for __copy_user() ?
If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in 
uaccess.h is always inlined. Maybe un-inlining helps?
Or, the inline-assembly for jsr/bsr needs tweeking ?

Helge 

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Richard Henderson]

On 10/24/2016 01:59 PM, Helge Deller wrote:
> Does it only happens for __copy_user() ?
> If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in
> uaccess.h is always inlined. Maybe un-inlining helps?
> Or, the inline-assembly for jsr/bsr needs tweeking ?

Indeed.  Try changing #ifdef MODULE above __copy_tofrom_user_nocheck to #if 1.


r~

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Michael Cree]

On Mon, Oct 24, 2016 at 08:13:22PM -0700, Richard Henderson wrote:
> On 10/24/2016 01:59 PM, Helge Deller wrote:
> > Does it only happens for __copy_user() ?
> > If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in
> > uaccess.h is always inlined. Maybe un-inlining helps?
> > Or, the inline-assembly for jsr/bsr needs tweeking ?
> 
> Indeed.  Try changing #ifdef MODULE above __copy_tofrom_user_nocheck to #if 1.

Thanks, that indeed fixes it.

While I have your ears (or eyes since this is email) I have been
running the ltp tests and noted some syscall test failures.  The sendmsg
call fails with a segfault instead of returning EFAULT, when one passes
in a NULL for the message arg.  When the test is run under gdb it
reports the segfault in the libc sendmsg function at the instruction
immediately following the syscall instruction and that instruction is a
move of a register to another register, not a memory access.  Would I
be correct in surmising that the segfault actually occurred in kernel
code but gets reported at the instruction following the syscall
instruction in user space?  (But looking at the kernel source for
sys_sendmsg it looks to me that the msg argument is properly checked
before being accessed so why a segfault should occur is not
obvious...)

(I see fstatfs also segfaults when passed a bad pointer but that's
because libc does not pass the bad address to the kernel, but
passes the address of a temporary buffer from which libc then
copies back into the bad address, thus kaboom instead of EFAULT.
C'est la vie.)

And while I mention gdb, it no longer works on Alpha since version
7.10.  Richard, would you be able to take a look at the bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=19061

And while I mention libc I am seeing (rather rare) random segfaults
in programs such as cp, tar, install and dpkg ever since the upgrade
to glibc 2.23 (or maybe it was 2.24).  I am struggling to get a
backtrace because it only happens very occassionally (but often enough
that it is almost impossible for a build and install of large software
packages such as libreoffice to complete without failure at some
random point) and when I rerun the failing program manually it then
always works.  I'll keep trying to narrow this one down.

Cheers
Michael.

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Richard Henderson]

On 10/25/2016 01:26 AM, Michael Cree wrote:
> On Mon, Oct 24, 2016 at 08:13:22PM -0700, Richard Henderson wrote:
>> On 10/24/2016 01:59 PM, Helge Deller wrote:
>>> Does it only happens for __copy_user() ?
>>> If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in
>>> uaccess.h is always inlined. Maybe un-inlining helps?
>>> Or, the inline-assembly for jsr/bsr needs tweeking ?
>>
>> Indeed.  Try changing #ifdef MODULE above __copy_tofrom_user_nocheck to #if 1.
> 
> Thanks, that indeed fixes it.
> 
> While I have your ears (or eyes since this is email) I have been
> running the ltp tests and noted some syscall test failures.  The sendmsg
> call fails with a segfault instead of returning EFAULT, when one passes
> in a NULL for the message arg.  When the test is run under gdb it
> reports the segfault in the libc sendmsg function at the instruction
> immediately following the syscall instruction and that instruction is a
> move of a register to another register, not a memory access.  Would I
> be correct in surmising that the segfault actually occurred in kernel
> code but gets reported at the instruction following the syscall
> instruction in user space?

That would be my assumption.

> (But looking at the kernel source for
> sys_sendmsg it looks to me that the msg argument is properly checked
> before being accessed so why a segfault should occur is not
> obvious...)

Indeed, I don't see anything wrong with copy_msghdr_from_user.

> 
> (I see fstatfs also segfaults when passed a bad pointer but that's
> because libc does not pass the bad address to the kernel, but
> passes the address of a temporary buffer from which libc then
> copies back into the bad address, thus kaboom instead of EFAULT.
> C'est la vie.)

Yep.

> 
> And while I mention gdb, it no longer works on Alpha since version
> 7.10.  Richard, would you be able to take a look at the bug report:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19061

Ah, yes.  I'll put that on my to-do list.

> And while I mention libc I am seeing (rather rare) random segfaults
> in programs such as cp, tar, install and dpkg ever since the upgrade
> to glibc 2.23 (or maybe it was 2.24).  I am struggling to get a
> backtrace because it only happens very occassionally (but often enough
> that it is almost impossible for a build and install of large software
> packages such as libreoffice to complete without failure at some
> random point) and when I rerun the failing program manually it then
> always works.  I'll keep trying to narrow this one down.

Hmm.  I don't recall having seen such a thing.  But then, I can't recall the
last time I did anything more than test glibc in situ, which doesn't show these
sorts of things.  Perhaps I should do a test install to a sysroot or something...


r~

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Richard Henderson]

On 10/25/2016 01:26 AM, Michael Cree wrote:
> And while I mention gdb, it no longer works on Alpha since version
> 7.10.  Richard, would you be able to take a look at the bug report:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19061

In the PR, Pedro has exactly the right pointer to the problem.

From arch/alpha/kernel/traps.c:

    info.si_signo = SIGTRAP;
    info.si_errno = 0;
    info.si_code = TRAP_BRKPT;
    info.si_trapno = 0;
    info.si_addr = (void __user *) regs->pc;

    if (ptrace_cancel_bpt(current)) {
        regs->pc -= 4;  /* make pc point to former bpt */
    }

So we report the same si_code for executing a breakpoint insn inserted by gdb,
and a "hardware" breakpoint managed by the kernel.  But for the later, we
already back up the PC.

So gdb winds up backing up the PC twice.

This ought to be fixed by using TRAP_HWBKPT (4) for the ptrace_cancel_bpt case,
but telling gdb about the issue in gdb/nat/linux-ptrace.c like so:

#elif defined __alpha__
# define GDB_ARCH_IS_TRAP_BRKPT(X)  ((X) == TRAP_BRKPT)
# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_BRKPT || (X) == TRAP_HWBKPT)

which looks confusing, but does get checked:

    if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)
        && GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
      {
        /* The si_code is ambiguous on this arch -- check debug
           registers.  */
        if (!check_stopped_by_watchpoint (lp))
          lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;

but at the moment the default definition of GDB_ARCH_IS_TRAP_HWBKPT is always
false for alpha.

Another fix would be to completely disable gdb's use of "hardware" breakpoints
for alpha.  Are they really more efficient than letting gdb manage everything?


r~

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Michael Cree]

On Tue, Oct 25, 2016 at 11:07:38AM -0700, Richard Henderson wrote:
> On 10/25/2016 01:26 AM, Michael Cree wrote:
> > And while I mention gdb, it no longer works on Alpha since version
> > 7.10.  Richard, would you be able to take a look at the bug report:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19061
> 
> In the PR, Pedro has exactly the right pointer to the problem.
> 
> >From arch/alpha/kernel/traps.c:
> 
>     info.si_signo = SIGTRAP;
>     info.si_errno = 0;
>     info.si_code = TRAP_BRKPT;
>     info.si_trapno = 0;
>     info.si_addr = (void __user *) regs->pc;
> 
>     if (ptrace_cancel_bpt(current)) {
>         regs->pc -= 4;  /* make pc point to former bpt */
>     }
> 
> So we report the same si_code for executing a breakpoint insn inserted by gdb,
> and a "hardware" breakpoint managed by the kernel.  But for the later, we
> already back up the PC.
> 
> So gdb winds up backing up the PC twice.
> 
> This ought to be fixed by using TRAP_HWBKPT (4) for the ptrace_cancel_bpt case,
> but telling gdb about the issue in gdb/nat/linux-ptrace.c like so:
> 
> #elif defined __alpha__
> # define GDB_ARCH_IS_TRAP_BRKPT(X)  ((X) == TRAP_BRKPT)
> # define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_BRKPT || (X) == TRAP_HWBKPT)
> 
> which looks confusing, but does get checked:
> 
>     if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)
>         && GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
>       {
>         /* The si_code is ambiguous on this arch -- check debug
>            registers.  */
>         if (!check_stopped_by_watchpoint (lp))
>           lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;
> 
> but at the moment the default definition of GDB_ARCH_IS_TRAP_HWBKPT is always
> false for alpha.

By saying "This ought to be fixed by [...] but at the moment [...]"
are you saying that the fix provided above will not work?  Indeed,
it doesn't work: I tried it and just about every test in the gdb test
suite still fails.  For example:

Running
/home/mjc/toolchain/gdb-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/break.exp
...
FAIL: gdb.base/break.exp: run until function breakpoint (timeout)
FAIL: gdb.base/break.exp: list marker1 (timeout)
FAIL: gdb.base/break.exp: break lineno (timeout)
FAIL: gdb.base/break.exp: delete $bpnum (timeout)
FAIL: gdb.base/break.exp: run until breakpoint set at a line number
(timeout)
FAIL: gdb.base/break.exp: run until file:function(6) breakpoint
(timeout)

Cheers
Michael.

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Richard Henderson]

On 10/25/2016 11:56 PM, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 11:07:38AM -0700, Richard Henderson wrote:
>> On 10/25/2016 01:26 AM, Michael Cree wrote:
>>> And while I mention gdb, it no longer works on Alpha since version
>>> 7.10.  Richard, would you be able to take a look at the bug report:
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=19061
>>
>> In the PR, Pedro has exactly the right pointer to the problem.
>>
>> >From arch/alpha/kernel/traps.c:
>>
>>     info.si_signo = SIGTRAP;
>>     info.si_errno = 0;
>>     info.si_code = TRAP_BRKPT;
>>     info.si_trapno = 0;
>>     info.si_addr = (void __user *) regs->pc;
>>
>>     if (ptrace_cancel_bpt(current)) {
>>         regs->pc -= 4;  /* make pc point to former bpt */
>>     }
>>
>> So we report the same si_code for executing a breakpoint insn inserted by gdb,
>> and a "hardware" breakpoint managed by the kernel.  But for the later, we
>> already back up the PC.
>>
>> So gdb winds up backing up the PC twice.
>>
>> This ought to be fixed by using TRAP_HWBKPT (4) for the ptrace_cancel_bpt case,
>> but telling gdb about the issue in gdb/nat/linux-ptrace.c like so:
>>
>> #elif defined __alpha__
>> # define GDB_ARCH_IS_TRAP_BRKPT(X)  ((X) == TRAP_BRKPT)
>> # define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_BRKPT || (X) == TRAP_HWBKPT)
>>
>> which looks confusing, but does get checked:
>>
>>     if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)
>>         && GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
>>       {
>>         /* The si_code is ambiguous on this arch -- check debug
>>            registers.  */
>>         if (!check_stopped_by_watchpoint (lp))
>>           lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;
>>
>> but at the moment the default definition of GDB_ARCH_IS_TRAP_HWBKPT is always
>> false for alpha.
> 
> By saying "This ought to be fixed by [...] but at the moment [...]"
> are you saying that the fix provided above will not work? 

What I meant is "this is what I'm going to try".  And then forgot about the
(annoyingly long) build I'd left running yesterday.

> Indeed,
> it doesn't work: I tried it and just about every test in the gdb test
> suite still fails.  For example:
> 
> Running
> /home/mjc/toolchain/gdb-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/break.exp
> ...
> FAIL: gdb.base/break.exp: run until function breakpoint (timeout)
> FAIL: gdb.base/break.exp: list marker1 (timeout)
> FAIL: gdb.base/break.exp: break lineno (timeout)
> FAIL: gdb.base/break.exp: delete $bpnum (timeout)
> FAIL: gdb.base/break.exp: run until breakpoint set at a line number
> (timeout)
> FAIL: gdb.base/break.exp: run until file:function(6) breakpoint
> (timeout)

Ok.  Well, I hope to get back to it soon.


r~

Alpha Kernel Regression [was Re: BRSGP relocation truncations in linking kernel for Alpha.]

[Michael Cree]

On Tue, Oct 25, 2016 at 09:26:38PM +1300, Michael Cree wrote:
> And while I mention libc I am seeing (rather rare) random segfaults
> in programs such as cp, tar, install and dpkg ever since the upgrade
> to glibc 2.23 (or maybe it was 2.24).  I am struggling to get a
> backtrace because it only happens very occassionally (but often enough
> that it is almost impossible for a build and install of large software
> packages such as libreoffice to complete without failure at some
> random point) and when I rerun the failing program manually it then
> always works.  I'll keep trying to narrow this one down.

It's not glibc.  Downgrading to previously known working versions does
not solve the random segfaults.  But downgrading the kernel does fix
the problem on Alpha.  Noted that 4.6 is good but 4.6.7 is bad so
bisected the 4.6.y stable kernel branch to get the first bad commit as
0784672d05684de901fc2aa56150d7ea9a475a2d, i.e.:

commit 0784672d05684de901fc2aa56150d7ea9a475a2d
Author: Chen Feng <puck.chen@hisilicon.com>
Date:   Fri May 20 16:59:02 2016 -0700

    mm/compaction.c: fix zoneindex in kcompactd()
    
    commit 6cd9dc3e75078ef646076fa63adfb9b85ced0b66 upstream.
    
    While testing the kcompactd in my platform 3G MEM only DMA ZONE.  I
    found the kcompactd never wakeup.  It seems the zoneindex has already
    minus 1 before.  So the traverse here should be <=.
    
    It fixes a regression where kswapd could previously compact, but
    kcompactd not.  Not a crash fix though.

Cheers
Michael.

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Thorsten Kranzkowski]

On Mon, Oct 24, 2016 at 08:13:22PM -0700, Richard Henderson wrote:
> On 10/24/2016 01:59 PM, Helge Deller wrote:
> >Does it only happens for __copy_user() ?
> >If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in
> >uaccess.h is always inlined. Maybe un-inlining helps?
> >Or, the inline-assembly for jsr/bsr needs tweeking ?
> 
> Indeed.  Try changing #ifdef MODULE above __copy_tofrom_user_nocheck to #if 1.

That makes the BRSGP issue go away for me as well. Yippie! It was a 
long-standing nuisance for me.


Now I only have this one left:

  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
arch/alpha/lib/lib.a(strcat.o): In function `strcat':
(.text+0x60): relocation truncated to fit: BRADDR against symbol `__stxcpy' defined in .text section in arch/alpha/lib/lib.a(ev6-stxcpy.o)
arch/alpha/lib/lib.a(strncat.o): In function `strncat':
(.text+0x60): relocation truncated to fit: BRADDR against symbol `__stxncpy' defined in .text section in arch/alpha/lib/lib.a(ev6-stxncpy.o)
make[1]: *** [vmlinux] Error 1
make[1]: Leaving directory `/usr/src/linux-ds20'
make: *** [sub-make] Error 2

Anything for me to try? 


Thanks,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |