On Fri, 14 Jul 2023 14:34:04 +0900 <kkabe@xxxxxxxxxxx> 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. 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
