linux-kernel - Re: radeon.ko/i586: BUG: kernel NULL pointer dereference,address:00000004

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: <230715113911.M0124687@vega.pgw.jp>
Date:   Sat, 15 Jul 2023 11:39:11 +0900
From:   <kkabe@...a.pgw.jp>
To:     rostedt@...dmis.org
Cc:     kkabe@...a.pgw.jp, regressions@...ts.linux.dev,
        bagasdotme@...il.com, alexander.deucher@....com,
        christian.koenig@....com, Xinhui.Pan@....com, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        hpa@...or.com, linux-kernel@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org
Subject: Re: radeon.ko/i586: BUG: kernel NULL pointer dereference,address:00000004

rostedt@...dmis.org sed in <20230714100019.6bf9b1ab@...dalf.local.home>

>> On Fri, 14 Jul 2023 14:34:04 +0900
>> <kkabe@...a.pgw.jp> wrote:
>> 
>> > >> > So I'm confused about why it's mentioned. Was it backported?  
>> > >> 
>> > >> Taketo Kabe, could you please help to clean this confusion up? Did you
>> > >> mean 5.19 in https://bugzilla.kernel.org/show_bug.cgi?id=217669#c5 ? And
>> > >> BTW: did you really use a vanilla kernel for your bisection?  
>> > 
>> > 
>> > Reporter Me:
>> > I bisected using freedesktop.org kernel tree, which git commit ID is
>> > in sync with kernel.org
>> > but version number in ./Makefile could be slighty behind. 
>> > 
>> > Patch in
>> > https://bugzilla.kernel.org/show_bug.cgi?id=217669#c4
>> > fixed the problem in freedesktop.org kernel 5.18.0-rc2 .
>> > This may explain that in kernel.org tree, the said commit is in kernel-5.19.
>> 
>> Even if the bisect did land on this commit, it doesn't make sense. I would
>> think that one of the results of the bisect was incorrect (a pass that
>> should have failed?), as that would lead the bisect down to the wrong
>> conclusion.
>> 
>> Now if you you remove this commit and everything works fine, and add it
>> back again and it fails reliably, then I can't argue it is not the commit.

I agree with that it does not make sense.
But reverting that commit made the freedesktop.org kernel-5.18-0-rc2 not panic,
and adding it back made kernel panic
(actually, check for vblank->worker==NULL fires)

>> 
>> But the commit in question kicks off a worker thread at boot up to search
>> for weak functions that were tagged to be traced by the function tracer and
>> sets them to "disabled" to never be traced.
>> 
>> Is the function tracer used at all here? I really do not see how this
>> commit affects the code that is crashing. Unless there's something wrong
>> with the way the kworker was set up and it corrupted other kworkers :-/
>> -- Steve

Yes, this is puzzling. That's why I need other people's opinion on this.
Does it matter the DUT is a slow machine (Pentium 120MHz)?

-- 
kabe