[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250331123649.GCZ-qMYfyI9gZWwFRm@fat_crate.local>
Date: Mon, 31 Mar 2025 14:36:49 +0200
From: Borislav Petkov <bp@...en8.de>
To: Philip Li <philip.li@...el.com>
Cc: Ingo Molnar <mingo@...nel.org>, lkp@...el.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] objtool fixes and updates
On Mon, Mar 31, 2025 at 08:31:08PM +0800, Philip Li wrote:
> For 0a7fb6f07e3a, the bot only reported 2 times on x86 [1][2]. For this
> loongarch report, the bisection is wrong and is a false positive, I will
> further check. Meanwhile, the bot will ignore the bisection of this new
> objtool message as it is not really a new kernel issue.
Can you guys get a human being to double-check and vet those reports?! Please!
Because we kinda trust them but
1. they're not really helpful and hard to understand what you're reporting
2. that summary thing is especially useless:
"Error/Warning ids grouped by kconfigs:
recent_errors
`-- loongarch-randconfig-001-20250328
`-- arch-loongarch-kernel-traps.o:warning:objtool:show_stack:skipping-duplicate-warning(s)"
When I see this, I need to go look for the original reports and somehow
scratch them together. And you have all that info, why don't you simply dump
a URL with the bug materials so that one can inspect them?
3. Last but not least, if this doesn't change I will start ignoring them.
Because they're not really helping - on the contrary - they're actively
interfering.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists