Re: [tip:tmp.tmp] [sched/fair] eb2db043ab: BUG:kernel_NULL_pointer_dereference,address

[Ingo Molnar <mingo@kernel.org>]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Nov 28, 2025 at 09:42:04AM +0800, Oliver Sang wrote:
> > hi,
> > 
> > On Thu, Nov 27, 2025 at 10:07:28AM +0100, Ingo Molnar wrote:
> > > 
> > > * Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Thu, Nov 27, 2025 at 04:35:37PM +0800, kernel test robot wrote:
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > kernel test robot noticed "BUG:kernel_NULL_pointer_dereference,address" on:
> > > > > 
> > > > > commit: eb2db043ab3a28ae76800f2a57e144420800d56d ("sched/fair: Skip sched_balance_running cmpxchg when balance is not due")
> > > > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git tmp.tmp
> > > > 
> > > > Not sure what this branch is, but tip/sched/core has the fixed commit.
> > > 
> > > Not sure how the test-bot picked up this temporary 
> > > branch and reported it despite it being gone from the 
> > > repo, but the branch hasn't been in -tip for days.
> > > 
> > > This report can be safely ignored.
> > 
> > sorry for the noise. yeah, our so-called 'gitmirror' mechnism fetched the
> > tmp.tmp branch about 10 days ago, then it merged into our hourly kernel to
> > be running tests. so it's kind of 'stored' in our repo.
> > 
> > since the bad commit caused crash issue on various test machines, we made out
> > the report, but missed the check of whether branch is still existing remotely.
> > 
> > we will refine our code/process to avoid this kind of meaningless report.
> 
> Might it make sense to exclude all branches named tmp ?

So the tmpfs project might disagree. ;-)

But a '^tmp\.' prefix exclusion pattern should be 
pretty robust IMO.

> [...] IIRC there are some patterns that the robot 
> skips over, but I forever forget what they are :/

I'm curious about those patterns, although 99% of the 
time I'm *happy* when the LKP robot finds a new 
development branch that I pushed out, quite often it 
will find bugs that my own testing doesn't catch, and 
the reports are useful & relevant these days. Beyond 
the bugreports the 'SUCCESS' reports are useful as 
well, as they can be used to phase the flow of 
development commits. So no complaints from me.

This tmp.tmp case was an exception to the rule really, 
and given the overwhelmingly positive net utility of 
the LKP test-bot I'd just ignore it, especially since 
the LKP bot was technically correct and the crashes 
were real (albeit fixed already).

Thanks,

	Ingo