Re: slowly decommission bugzilla?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sun, 2026-03-01 at 11:16 -0500, Sasha Levin wrote:
> 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.

In your report it identified a commit.  The next step it could take
would surely be reverting that in a kernel the reporter can try.  In
this particular case I admit the candidate commit looks like it won't
easily revert, so perhaps based on the LLM's own advice, it could
construct a patch and try that instead?

[...]
> 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 :)

Well, that gets us on to the problem of who pays for all our AI use;
but while they're willing, I'm sure we can tap the vast funding
resources of AI companies for this.

But since ksymoops already did it, there is a more deterministic way of
picking oops reports off the lists before handing them over to AI.


Regards,

James