linux-kernel - Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.

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: <161662E3-5D9C-4C15-919C-CFEFE4CC35CB@lca.pw>
Date:   Wed, 15 Apr 2020 11:57:50 -0400
From:   Qian Cai <cai@....pw>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Nicholas Piggin <npiggin@...il.com>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.



> On Apr 10, 2020, at 3:20 PM, Qian Cai <cai@....pw> wrote:
> 
> 
> 
>> On Apr 9, 2020, at 10:14 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>> 
>> On Thu, 9 Apr 2020 06:06:35 -0400
>> Qian Cai <cai@....pw> wrote:
>> 
>>>>> I’ll go to bisect some more but it is going to take a while.
>>>>> 
>>>>> $ git log --oneline 4c205c84e249..8e99cf91b99b
>>>>> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
>>>>> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
>>>>> ebed9628f5c2 selftests/ftrace: Add test to test new set_event_notrace_pid file
>>>>> ed8839e072b8 selftests/ftrace: Add test to test new set_ftrace_notrace_pid file
>>>>> 276836260301 tracing: Create set_event_notrace_pid to not trace tasks  
>>>> 
>>>>> b3b1e6ededa4 ftrace: Create set_ftrace_notrace_pid to not trace tasks
>>>>> 717e3f5ebc82 ftrace: Make function trace pid filtering a bit more exact  
>>>> 
>>>> If it is affecting function tracing, it is probably one of the above two
>>>> commits.  
>>> 
>>> OK, it was narrowed down to one of those messed with mcount here,
>> 
>> Thing is, nothing here touches mcount.
> 
> Yes, you are right. I went back to test the commit just before the 5.7-trace merge request,
> I did reproduce there. The thing is that this bastard could take more 6-hour to happen,
> so my previous attempt did not wait long enough. Back to the square one…

OK, I starts to test all commits up to 12 hours. The progess on far is,

BAD: v5.6-rc1
GOOD: v5.5
GOOD: 153b5c566d30 Merge tag 'microblaze-v5.6-rc1' of git://git.monstr.eu/linux-2.6-microblaze

The next step I’ll be testing,

71c3a888cbca Merge tag 'powerpc-5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

IF that is BAD, the merge request is the culprit. I can see a few commits are more related that others.

5290ae2b8e5f powerpc/64: Use {SAVE,REST}_NVGPRS macros
ed0bc98f8cbe powerpc/64s: Reimplement power4_idle code in C

Does it ring any bell yet?