Re: [PATCH] xfs: fix out-of-bounds write from crafted btree root numrecs during log recovery

[Dave Chinner]

On Thu, Oct 29, 2026 at 08:37:06AM -0600, Jonathan Corbet wrote:
> Dave Chinner <dgc@xxxxxxxxxx> writes:
> 
> > On Wed, Oct 28, 2026 at 04:43:37PM -0600, Jonathan Corbet wrote:
> >> Dave Chinner <dgc@xxxxxxxxxx> writes:
> >> 
> >> > Unless you know how to fix the discovered problem correctly, don't
> >> > send what your LLM proposed for review. It will be garbage, and all
> >> > that will do is annoy whoever has to review it. Just report the bug,
> >> > let the subsystem developers fix it.
> >> 
> >> Just to be obnoxious...this runs counter to the advice we have in
> >> Documentation/process/security-bugs.rst, where reporters are requested
> >> to include a proposed fix as well.  It seems we're sending a bit of a
> >> mixed message...
> >
> > These aren't security bugs. Bugs that result from maliciously
> > corrupted filesystem images (i.e. fuzzed) are explicitly stated as
> > not covered by the kernel security threat models. IOWs, they are
> > just -bugs-, and bugs that just don't ever happen in the real world.
> 
> I wasn't arguing about the nature of the bug ... just noting the
> disconnect with what I've heard from some maintainers, who say that
> providing a patch helps in the identification of the problem, even if
> the patch is not used.

In this day and age, feeding a bug description to an LLM to get an
analysis of the issue takes less time and is more informative than
trying to get the same information from a patch generated by an LLM
to 'fix' the problem.

It's verifying the correctness of the root cause analysis that is
important here, not the code review.  LLMs frequently miss important
stuff that experienced developers know, and it's that wider context
that makes all the difference.

With everyone presenting fixes rather than bugs now, we end up
having to reverse engineer both the problem and why the specific fix
was chosen during code review. The typical commit message is
opaque and doesn't describe the symptoms that the bug exhibited.
This makes "code review" much harder and more time consuming than if
the bug was simply reported to the list.

After a year of using LLMs to write code and fixing complex bugs, I
know that an LLM requires its context to be properly primed for it
to generate a solid fix rather than a copy-pasted band-aid. It needs
to understand abstractions, other code that does similar things,
pre-exiting helper functions, etc. These generally lie outside the
immeidate scope of the code containing the bug. This is where the
experience and skill of the person running the LLM make all the
difference.

IOWs, the important part of fixing a bug with an LLM is running an
extensive, guided root cause analysis process to fully prime the
context window. Hence I want comprehensive bug reports to run the
analysis process on, not have to try and recreate that from somebody
(or something) else's interpretation of how the bug should be
fixed....

-Dave.
-- 
Dave Chinner
dgc@xxxxxxxxxx