lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f90742a02398f03f715b2a9afef213f5dee8f2bf.camel@intel.com>
Date:   Tue, 15 Aug 2023 07:34:04 +0000
From:   "Liu, Yujie" <yujie.liu@...el.com>
To:     "paulmck@...nel.org" <paulmck@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        lkp <lkp@...el.com>,
        "oe-kbuild-all@...ts.linux.dev" <oe-kbuild-all@...ts.linux.dev>
Subject: Re: {standard input}:1727: Error: operand out of range (-132 is not
 between -128 and 127)

Hi Paul,

On Fri, 2023-08-11 at 08:41 -0700, Paul E. McKenney wrote:
> On Fri, Aug 11, 2023 at 01:02:12PM +0800, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head:   25aa0bebba72b318e71fe205bfd1236550cc9534
> > commit: a6889becb05394255c80b62103677e3b095726a9 refscale: Add tests using SLAB_TYPESAFE_BY_RCU
> > date:   7 months ago
> > config: arc-randconfig-r006-20230811 (https://download.01.org/0day-ci/archive/20230811/202308111233.rbf5C0JD-lkp@intel.com/config)
> > compiler: arceb-elf-gcc (GCC) 12.3.0
> > reproduce: (https://download.01.org/0day-ci/archive/20230811/202308111233.rbf5C0JD-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > > Reported-by: kernel test robot <lkp@...el.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202308111233.rbf5C0JD-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    {standard input}: Assembler messages:
> > > > {standard input}:1727: Error: operand out of range (-132 is not between -128 and 127)
> 
> I am not seeing any inline assembly in that patch, so I have to suspect
> a bug in arch code or the compiler backend for arc.
> 
> Or is there something that I am missing here?

We looked into this case a little bit. The assembler error popped up
when building kernel/rcu/refscale.o

$make W=1 --keep-going CROSS_COMPILE=arceb-elf- ARCH=arc kernel/rcu/refscale.o
...
  CC [M]  kernel/rcu/refscale.o
{standard input}: Assembler messages:
{standard input}:1727: Error: operand out of range (-132 is not between -128 and 127)
make[3]: *** [scripts/Makefile.build:252: kernel/rcu/refscale.o] Error 1
make[2]: *** [scripts/Makefile.build:504: kernel/rcu] Error 2
make[2]: Target 'kernel/rcu/refscale.o' not remade because of errors.
make[1]: *** [scripts/Makefile.build:504: kernel] Error 2
make[1]: Target 'kernel/rcu/refscale.o' not remade because of errors.
make: *** [Makefile:2008: .] Error 2
make: Target 'kernel/rcu/refscale.o' not remade because of errors.

We did some assembly and disassembly tricks:

1721 .L334:
1722         ld_s    r0,[r14,52]             ;15
1723         brgt r0, r19, @.L335
1724         ld_s    r0,[r13,120]            ;15
1725         breq_s r0, 0, @.L337
1726         jl [r17]
1727         brne_s r0, 0, @.L337    <---
1728         mov_s   r2,20   ;3
1729         mov_s   r1,0    ;3
1730         mov_s   r0,sp   ;4
1731         jl [r20]
1732         mov_s   r1,0    ;3
1733         mov_s   r0,sp   ;4
1734         jl @init_wait_entry
1735         .align 2

This assembly instruction at line 1727 points to the code in main_func,
but main_func is not touched by commit a6889becb053.

 d6e:   860d                    ld_s    r0,[r14,0x34]
 d70:   0b59 a002               brlt.nt r19,r0,-168     ;cc8 <main_func+0x16c>
        return arch_atomic_read(v);
 d74:   851e                    ld_s    r0,[r13,0x78]
                wait_event(main_wq,
 d76:   e842                    breq_s  r0,0,-124       ;cf8 <main_func+0x19c>
 d78:   2022 0440               jl      [r17]
 d7c:   e8be                    brne_s  r0,0,124        ;df8 <main_func+0x29c>   <--
 d7e:   da14                    mov_s   r2,0x14
 d80:   702c                    mov_s   r1,0
 d82:   4083                    mov_s   r0,sp
 d84:   2022 0500               jl      [r20]
 d88:   702c                    mov_s   r1,0
 d8a:   4083                    mov_s   r0,sp
 d8c:   2022 0f80 0000 0000     jl      0

We also tried on the parent commit 3c6496c86e48. It builds fine without
that assembler error, and corresponding disassembly is:

 afe:   860d                    ld_s    r0,[r14,0x34]
 b00:   0b5d a002               brlt.nt r19,r0,-164     ;a5c <main_func+0x16c>
        return arch_atomic_read(v);
 b04:   8518                    ld_s    r0,[r13,0x60]
                wait_event(main_wq,
 b06:   e844                    breq_s  r0,0,-120       ;a8c <main_func+0x19c>
 b08:   2022 0440               jl      [r17]
 b0c:   e8c0                    brne_s  r0,0,-128       ;a8c <main_func+0x19c>   <--
 b0e:   da14                    mov_s   r2,0x14
 b10:   702c                    mov_s   r1,0
 b12:   4083                    mov_s   r0,sp
 b14:   2022 0500               jl      [r20]
 b18:   702c                    mov_s   r1,0
 b1a:   4083                    mov_s   r0,sp
 b1c:   2022 0f80 0000 0000     jl      0
 b24:   724c                    mov_s   r2,2
 b26:   4183                    mov_s   r1,sp
 b28:   40c3 0000 0000          mov_s   r0,0
 b2e:   2022 0f80 0000 0000     jl      0


We are also not sure if this is a bug in arch code or compiler side.
Here we provide above info for your reference.

--
Best Regards,
Yujie

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ