Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 7 Feb 2022 23:31:41 +0800
From:   Jisheng Zhang <jszhang@kernel.org>
To:     ChangbinCONFIG_IRQSOFF_TRACER Du <changbin.du@gmail.com>
Cc:     Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] riscv: fix oops caused by irq on/off tracer
Message-ID: <YgE7XRE/Uc6gTCWd@xhacker>
References: <20220129004226.32868-1-changbin.du@gmail.com>
 <YgAEb425uqy5/dw1@xhacker>
 <20220207123850.l4r5qjswaegwisbx@mail.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220207123850.l4r5qjswaegwisbx@mail.google.com>
Precedence: bulk

On Mon, Feb 07, 2022 at 08:38:50PM +0800, ChangbinCONFIG_IRQSOFF_TRACER Du wrote:
> On Mon, Feb 07, 2022 at 01:25:03AM +0800, Jisheng Zhang wrote:
> > On Sat, Jan 29, 2022 at 08:42:26AM +0800, Changbin Du wrote:
> > > The trace_hardirqs_on/off requires at least two parent call frames.
> > > If not, the code generated by CALLER_ADDR1 (aka. ftrace_return_address(1))
> > > could trigger memory access fault.
> > > 
> > > [    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
> > > [    0.041925][    T0] Oops [#1]
> > > [    0.042063][    T0] Modules linked in:
> > > [    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29
> > > [    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT)
> > > [    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2
> > > [    0.044601][    T0]  ra : restore_all+0x12/0x6e
> > > [    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0
> > > [    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020
> > > [    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0
> > > [    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100
> > > [    0.045046][    T0]  a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
> > > [    0.045124][    T0]  a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45
> > > [    0.045210][    T0]  s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50
> > > [    0.045289][    T0]  s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8
> > > [    0.045389][    T0]  s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000
> > > [    0.045474][    T0]  s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000
> > > [    0.045548][    T0]  t5 : 0000000000000000 t6 : ffffffff814aa368
> > > [    0.045620][    T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d
> > > [    0.046402][    T0] [<ffffffff80003b94>] restore_all+0x12/0x6e
> > > 
> > 
> > Hi Changbin,
> > 
> > Could you please provide the reproduce steps? It looks a bit
> > interesting.
> >
> Just enable CONFIG_IRQSOFF_TRACER and rebuild kernel with llvm. Then boot the
> new kernel.

Thanks for the information. I tried IRQSOFF_TRACER with gcc+binutils,
can't reproduce the issue. I forget to try clang+llvm. From another side
The fact that gcc+bintuils can't reproduce it means this is a clang+llvm
speicial case, no?