From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Poimboeuf Subject: Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be Date: Mon, 2 Oct 2017 16:26:54 -0500 Message-ID: <20171002212654.rsm4uj3hfioddldd@treble> References: <59d177a7.vsiddgOxdHRIlRvy%fengguang.wu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Torvalds Cc: kernel test robot , LKP , linux-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dma , linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , USB list , Vinod Koul , LKML , wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org List-Id: linux-arm-msm@vger.kernel.org On Mon, Oct 02, 2017 at 01:09:31PM -0700, Linus Torvalds wrote: > Bringing in Josh on this, because the merge commit gets fingered > because it seems to be an interaction between the new code from the > merge and the ORC unwinder changes. It's probably some almost trivial > code difference that just causes some code generation to change. > > And because Josh wasn't implicated in the merge, he didn't get cc'd by > the kernel test robot. > > Of course, the stack trace itself seems to be pretty useless, since > that randconfig doesn't have KALLSYMS enabled, so it's just random hex > numbers. > > Josh, original email on lkml and a few other mailing lists, see for example: > > https://www.spinics.net/lists/devicetree/msg196692.html > > Any ideas? The bisect is pointing to a commit which is almost 5 months old, so this is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart enough to realize it's dumping misaligned stack addresses: [ 110.399425] WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be [ 110.399428] unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0 [ 110.399431] bd92bc2e: 92bc7f00 (0x92bc7f00) [ 110.399433] bd92bc32: c27041bd (0xc27041bd) So kallsyms doesn't help if I'm dumping bad data. Oops. I tried to recreate it with the reproducer script and a similar GCC version, but no luck. Fengguang, assuming it's reliably recreatable, any chance you could recreate with the following patch? diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c index 82c6d7f1fd73..64282ec73eb8 100644 --- a/arch/x86/kernel/unwind_frame.c +++ b/arch/x86/kernel/unwind_frame.c @@ -42,7 +42,7 @@ static void unwind_dump(struct unwind_state *state) state->stack_info.type, state->stack_info.next_sp, state->stack_mask, state->graph_idx); - for (sp = state->orig_sp; sp; sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { + for (sp = PTR_ALIGN(state->orig_sp); sp; sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { if (get_stack_info(sp, state->task, &stack_info, &visit_mask)) break; -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8305347106832512613==" MIME-Version: 1.0 From: Josh Poimboeuf To: lkp@lists.01.org Subject: Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be Date: Mon, 02 Oct 2017 16:26:54 -0500 Message-ID: <20171002212654.rsm4uj3hfioddldd@treble> In-Reply-To: List-Id: --===============8305347106832512613== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Oct 02, 2017 at 01:09:31PM -0700, Linus Torvalds wrote: > Bringing in Josh on this, because the merge commit gets fingered > because it seems to be an interaction between the new code from the > merge and the ORC unwinder changes. It's probably some almost trivial > code difference that just causes some code generation to change. > = > And because Josh wasn't implicated in the merge, he didn't get cc'd by > the kernel test robot. > = > Of course, the stack trace itself seems to be pretty useless, since > that randconfig doesn't have KALLSYMS enabled, so it's just random hex > numbers. > = > Josh, original email on lkml and a few other mailing lists, see for examp= le: > = > https://www.spinics.net/lists/devicetree/msg196692.html > = > Any ideas? The bisect is pointing to a commit which is almost 5 months old, so this is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart enough to realize it's dumping misaligned stack addresses: [ 110.399425] WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:381= 1 has bad 'bp' value 000001be [ 110.399428] unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0 [ 110.399431] bd92bc2e: 92bc7f00 (0x92bc7f00) [ 110.399433] bd92bc32: c27041bd (0xc27041bd) So kallsyms doesn't help if I'm dumping bad data. Oops. I tried to recreate it with the reproducer script and a similar GCC version, but no luck. Fengguang, assuming it's reliably recreatable, any chance you could recreate with the following patch? diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c index 82c6d7f1fd73..64282ec73eb8 100644 --- a/arch/x86/kernel/unwind_frame.c +++ b/arch/x86/kernel/unwind_frame.c @@ -42,7 +42,7 @@ static void unwind_dump(struct unwind_state *state) state->stack_info.type, state->stack_info.next_sp, state->stack_mask, state->graph_idx); = - for (sp =3D state->orig_sp; sp; sp =3D PTR_ALIGN(stack_info.next_sp, size= of(long))) { + for (sp =3D PTR_ALIGN(state->orig_sp); sp; sp =3D PTR_ALIGN(stack_info.ne= xt_sp, sizeof(long))) { if (get_stack_info(sp, state->task, &stack_info, &visit_mask)) break; =20 --===============8305347106832512613==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: jpoimboe@redhat.com (Josh Poimboeuf) Date: Mon, 2 Oct 2017 16:26:54 -0500 Subject: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be In-Reply-To: References: <59d177a7.vsiddgOxdHRIlRvy%fengguang.wu@intel.com> Message-ID: <20171002212654.rsm4uj3hfioddldd@treble> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 02, 2017 at 01:09:31PM -0700, Linus Torvalds wrote: > Bringing in Josh on this, because the merge commit gets fingered > because it seems to be an interaction between the new code from the > merge and the ORC unwinder changes. It's probably some almost trivial > code difference that just causes some code generation to change. > > And because Josh wasn't implicated in the merge, he didn't get cc'd by > the kernel test robot. > > Of course, the stack trace itself seems to be pretty useless, since > that randconfig doesn't have KALLSYMS enabled, so it's just random hex > numbers. > > Josh, original email on lkml and a few other mailing lists, see for example: > > https://www.spinics.net/lists/devicetree/msg196692.html > > Any ideas? The bisect is pointing to a commit which is almost 5 months old, so this is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart enough to realize it's dumping misaligned stack addresses: [ 110.399425] WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be [ 110.399428] unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0 [ 110.399431] bd92bc2e: 92bc7f00 (0x92bc7f00) [ 110.399433] bd92bc32: c27041bd (0xc27041bd) So kallsyms doesn't help if I'm dumping bad data. Oops. I tried to recreate it with the reproducer script and a similar GCC version, but no luck. Fengguang, assuming it's reliably recreatable, any chance you could recreate with the following patch? diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c index 82c6d7f1fd73..64282ec73eb8 100644 --- a/arch/x86/kernel/unwind_frame.c +++ b/arch/x86/kernel/unwind_frame.c @@ -42,7 +42,7 @@ static void unwind_dump(struct unwind_state *state) state->stack_info.type, state->stack_info.next_sp, state->stack_mask, state->graph_idx); - for (sp = state->orig_sp; sp; sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { + for (sp = PTR_ALIGN(state->orig_sp); sp; sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { if (get_stack_info(sp, state->task, &stack_info, &visit_mask)) break; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751613AbdJBV1B (ORCPT ); Mon, 2 Oct 2017 17:27:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47694 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751084AbdJBV07 (ORCPT ); Mon, 2 Oct 2017 17:26:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 49D3B821C3 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Mon, 2 Oct 2017 16:26:54 -0500 From: Josh Poimboeuf To: Linus Torvalds Cc: kernel test robot , LKP , linux-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, dma , linux-samsung-soc@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , USB list , Vinod Koul , LKML , wfg@linux.intel.com Subject: Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be Message-ID: <20171002212654.rsm4uj3hfioddldd@treble> References: <59d177a7.vsiddgOxdHRIlRvy%fengguang.wu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 02 Oct 2017 21:26:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 02, 2017 at 01:09:31PM -0700, Linus Torvalds wrote: > Bringing in Josh on this, because the merge commit gets fingered > because it seems to be an interaction between the new code from the > merge and the ORC unwinder changes. It's probably some almost trivial > code difference that just causes some code generation to change. > > And because Josh wasn't implicated in the merge, he didn't get cc'd by > the kernel test robot. > > Of course, the stack trace itself seems to be pretty useless, since > that randconfig doesn't have KALLSYMS enabled, so it's just random hex > numbers. > > Josh, original email on lkml and a few other mailing lists, see for example: > > https://www.spinics.net/lists/devicetree/msg196692.html > > Any ideas? The bisect is pointing to a commit which is almost 5 months old, so this is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart enough to realize it's dumping misaligned stack addresses: [ 110.399425] WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be [ 110.399428] unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0 [ 110.399431] bd92bc2e: 92bc7f00 (0x92bc7f00) [ 110.399433] bd92bc32: c27041bd (0xc27041bd) So kallsyms doesn't help if I'm dumping bad data. Oops. I tried to recreate it with the reproducer script and a similar GCC version, but no luck. Fengguang, assuming it's reliably recreatable, any chance you could recreate with the following patch? diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c index 82c6d7f1fd73..64282ec73eb8 100644 --- a/arch/x86/kernel/unwind_frame.c +++ b/arch/x86/kernel/unwind_frame.c @@ -42,7 +42,7 @@ static void unwind_dump(struct unwind_state *state) state->stack_info.type, state->stack_info.next_sp, state->stack_mask, state->graph_idx); - for (sp = state->orig_sp; sp; sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { + for (sp = PTR_ALIGN(state->orig_sp); sp; sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { if (get_stack_info(sp, state->task, &stack_info, &visit_mask)) break;