From: Sasha Levin <sashal@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Richard Weinberger <richard@nod.at>,
Linus Torvalds <torvalds@linuxfoundation.org>,
Thorsten Leemhuis <linux@leemhuis.info>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
users <users@kernel.org>, ksummit <ksummit@lists.linux.dev>
Subject: Re: slowly decommission bugzilla?
Date: Sun, 1 Mar 2026 11:16:04 -0500 [thread overview]
Message-ID: <aaRmRGzJutgAruJt@laps> (raw)
In-Reply-To: <f998ee02c352c316e747ce14148449bcbacf6cc7.camel@HansenPartnership.com>
On Sun, Mar 01, 2026 at 11:01:07AM -0500, James Bottomley wrote:
>On Sun, 2026-03-01 at 10:23 -0500, Sasha Levin wrote:
>[...]
>> As an example, this bug report came in today with no replies:
>>
>>
>> https://lore.kernel.org/all/DGRCO9SL0T5U.JTINSHJQ9KPK@imlonghao.com/
>>
>> I fed it to an LLM. It decoded the stack trace (as described above),
>> then traced the crash to iptfs_reassem_cont() at xfrm_iptfs.c:905:
>> skb_put() on a non-linear skb. It identified the offending commit
>> (5f2b6a9095743), the code author (Christian Hopps), the relevant
>> maintainers, and a couple more vulnerable call sites in the same
>> function. Not perfect, but enough to get the report to the right
>> people with useful context already attached.
>
>Lore says there's been no follow up to that email ... shouldn't someone
>check with the reporter that the fix actually works?
Hmm? I don't think that there's a fix available yet.
>> What I'd like to propose: set up something like bug@kernel.org with a
>> bot that watches it. When a report comes in, it:
>
>If we're going to link an agent to a mailing list, why not simply have
>it scan all of them? Something like the way the old ksymoops used to.
We could. In my mind a mail to bug@ would just be a marker for the bot to run
on. Do we have a better way to identify bug reports?
I don't want to send every single incoming mail through the LLM to determine if
it's a bug report or not. That would make it slightly expensive :)
>> 1. Pulls the oops/stack trace from the email (if exists)
>> 2. Figures out the kernel version, obtains or builds debuginfo, and
>> decodes the stack trace
>> 3. Reads the relevant source, identifies root cause, offending
>> commit,
>> and the right maintainers/lists
>> 4. Forwards the report with its analysis to the right list, Cc'ing
>> the right people
>>
>> One email address, no tooling required from the reporter, bugs get to
>> the right list with a decoded stack trace and first-pass analysis.
>> The analysis will be wrong sometimes, but even just the decoded trace
>> and correct routing is better than what bugzilla gives us today.
>
>If an agent is going to be doing this, then the agent could reply with
>the results and add the emails it deduced should be notified. You can
>add caveat phrases like "Hi I'm an automatic reply from a LLM and I
>think ..."
Yup! In this example, it would reply with the processed report (the one I
linked in the previous mail), but also cc the list of folks it identified in
the "Contacts" section.
>It also looks quite easy for the agent to identify whether this is a
>regression or not and flag that more clearly (and possibly follow up as
>well, which means we get regression tracking back).
Agree
--
Thanks,
Sasha
next prev parent reply other threads:[~2026-03-01 16:16 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 4:48 kernel.org tooling update Konstantin Ryabitsev
2025-12-10 8:11 ` Mauro Carvalho Chehab
2025-12-10 13:30 ` Thorsten Leemhuis
2025-12-11 3:04 ` Theodore Tso
2025-12-12 23:48 ` Stephen Hemminger
2025-12-12 23:54 ` Randy Dunlap
2025-12-16 16:21 ` Lukas Wunner
2025-12-16 20:33 ` Jeff Johnson
2025-12-17 0:47 ` Mario Limonciello
2025-12-18 13:37 ` Jani Nikula
2025-12-18 14:09 ` Mario Limonciello
2026-01-23 9:19 ` Web of Trust work [Was: kernel.org tooling update] Uwe Kleine-König
2026-01-23 9:29 ` Greg KH
2026-01-23 11:47 ` Mauro Carvalho Chehab
2026-01-23 11:58 ` Greg KH
2026-01-23 12:24 ` Mauro Carvalho Chehab
2026-01-23 12:29 ` Greg KH
2026-01-23 13:57 ` Konstantin Ryabitsev
2026-01-23 16:24 ` James Bottomley
2026-01-23 16:33 ` Greg KH
2026-01-23 16:42 ` Joe Perches
2026-01-23 17:00 ` Steven Rostedt
2026-01-23 17:23 ` James Bottomley
2026-01-23 18:23 ` Konstantin Ryabitsev
2026-01-23 21:12 ` Uwe Kleine-König
2026-01-26 16:23 ` Konstantin Ryabitsev
2026-01-26 17:32 ` Uwe Kleine-König
2026-01-26 21:01 ` Konstantin Ryabitsev
2026-01-26 23:23 ` James Bottomley
2026-01-27 8:39 ` Uwe Kleine-König
2026-01-27 21:08 ` Linus Torvalds
2026-02-04 10:49 ` Uwe Kleine-König
2026-02-05 10:14 ` James Bottomley
2026-02-05 18:07 ` Uwe Kleine-König
2026-02-05 18:23 ` Konstantin Ryabitsev
2026-01-26 23:33 ` Mauro Carvalho Chehab
2026-01-26 23:06 ` Mauro Carvalho Chehab
2026-01-23 21:38 ` James Bottomley
2026-01-23 22:55 ` Mauro Carvalho Chehab
2026-01-23 16:38 ` Konstantin Ryabitsev
2026-01-23 17:02 ` Paul Moore
2026-03-08 7:21 ` Uwe Kleine-König
2026-03-08 10:24 ` Greg KH
2026-03-18 14:02 ` Greg KH
2026-01-23 18:42 ` kernel.org tooling update Randy Dunlap
2026-02-26 8:44 ` slowly decommission bugzilla? (was: Re: kernel.org tooling update) Thorsten Leemhuis
2026-02-26 14:40 ` Andrew G. Morgan
2026-02-26 17:04 ` Andrew Morton
2026-02-27 11:07 ` Jani Nikula
2026-02-27 15:16 ` Steven Rostedt
2026-02-27 15:18 ` Mark Brown
2026-02-27 15:44 ` Steven Rostedt
2026-02-27 15:18 ` slowly decommission bugzilla? Sven Peter
2026-02-27 15:35 ` slowly decommission bugzilla? (was: Re: kernel.org tooling update) Richard Weinberger
2026-02-27 16:00 ` Geert Uytterhoeven
2026-02-27 16:22 ` Richard Weinberger
2026-02-27 16:29 ` Peter Zijlstra
2026-02-27 17:07 ` James Bottomley
2026-02-28 13:41 ` slowly decommission bugzilla? Thorsten Leemhuis
2026-02-28 15:17 ` Richard Weinberger
2026-02-28 17:40 ` Linus Torvalds
2026-02-28 18:29 ` Richard Weinberger
2026-02-28 20:26 ` Steven Rostedt
2026-02-28 20:28 ` Richard Weinberger
2026-02-28 20:56 ` Steven Rostedt
2026-03-01 15:23 ` Sasha Levin
2026-03-01 15:35 ` Laurent Pinchart
2026-03-01 15:42 ` Sasha Levin
2026-03-01 16:13 ` Laurent Pinchart
2026-03-01 16:27 ` Sasha Levin
2026-03-06 15:01 ` Laurent Pinchart
2026-03-07 16:19 ` Sasha Levin
2026-03-01 16:15 ` James Bottomley
2026-03-01 16:49 ` Laurent Pinchart
2026-03-02 8:55 ` Mauro Carvalho Chehab
2026-03-01 17:33 ` Linus Torvalds
2026-03-02 20:28 ` [RFC] kallsyms: embed source file:line info in kernel stack traces Sasha Levin
2026-03-03 5:39 ` Alexey Dobriyan
2026-03-03 12:44 ` Sasha Levin
2026-03-03 13:17 ` Steven Rostedt
2026-03-03 16:35 ` Sasha Levin
2026-03-06 15:22 ` Laurent Pinchart
2026-03-03 19:09 ` Alexey Dobriyan
2026-03-03 6:26 ` Richard Weinberger
2026-03-03 6:48 ` Tomasz Figa
2026-03-03 9:04 ` Vlastimil Babka (SUSE)
2026-03-03 12:45 ` Sasha Levin
2026-03-03 8:11 ` Geert Uytterhoeven
2026-03-03 9:31 ` Jiri Slaby
2026-03-03 12:47 ` Sasha Levin
2026-03-03 12:58 ` James Bottomley
2026-03-03 13:08 ` Jürgen Groß
2026-03-03 8:09 ` Geert Uytterhoeven
2026-03-03 22:44 ` Helge Deller
2026-03-03 22:47 ` Sasha Levin
2026-03-01 16:01 ` slowly decommission bugzilla? James Bottomley
2026-03-01 16:16 ` Sasha Levin [this message]
2026-03-01 16:25 ` James Bottomley
2026-03-01 16:33 ` Sasha Levin
2026-03-06 10:37 ` Richard Weinberger
2026-03-06 10:44 ` Geert Uytterhoeven
2026-03-15 14:58 ` Richard Weinberger
2026-03-16 11:28 ` Greg KH
2026-03-16 21:56 ` Richard Weinberger
2026-03-17 7:51 ` Greg Kroah-Hartman
2026-04-02 4:59 ` slowly decommission bugzilla? (was: Re: kernel.org tooling update) Konstantin Ryabitsev
2026-04-02 13:07 ` Theodore Tso
2026-04-02 13:28 ` Konstantin Ryabitsev
2026-04-02 14:08 ` Theodore Tso
2026-04-02 14:21 ` Konstantin Ryabitsev
2026-04-02 14:49 ` Steven Rostedt
2026-04-02 13:51 ` James Bottomley
2026-04-02 13:42 ` slowly decommission bugzilla? Thorsten Leemhuis
2026-04-02 14:04 ` Konstantin Ryabitsev
2026-04-02 14:15 ` Richard Weinberger
2026-04-02 15:45 ` Laurent Pinchart
2026-04-02 16:04 ` Thorsten Leemhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaRmRGzJutgAruJt@laps \
--to=sashal@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=geert@linux-m68k.org \
--cc=konstantin@linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=linux@leemhuis.info \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=torvalds@linuxfoundation.org \
--cc=users@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox