Re: slowly decommission bugzilla?

On Sun, Mar 01, 2026 at 11:25:32AM -0500, James Bottomley wrote:
>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/[email protected]/
>> > >
>> > > 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?

Ah

I'd probably want to avoid having it generate code and send it to users. I
don't want to take responsibility for potentially causing harm to their
systems.

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

If the volume of reports is somewhere in the single or double digits a day we
won't even need to ask for any extras :)

>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.

I suppose we can grep for "Call Trace" to catch those, but we should still have
a story around bug reports without call traces.

-- 
Thanks,
Sasha