[LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[James Bottomley]

To set the stage, we in SCSI have seen an uptick in patches to older
drivers mostly fixing missing free (data leak) and data race problems.
I'm not even sure they're all AI found, but we don't really need to
know that. The problem, that the submitters often don't appreciate, is
that every "fix" has some chance of being wrong, so it requires code
inspection (which is also not free, and which may get it wrong too) and
testing, for which, often, no-one has any immediate hardware. The
problems we see is that missed frees (often in error legs) represent
tiny amounts of memory over the lifetime of the driver (they're often
in the remove legs) and so we have to ask set against the risk of a
wrong patch, is the problem even worth fixing? The same goes for data
races ... and here the suggested fixes are often somewhat complex and,
on analysis, problematic in some way. I've cc'd fsdevel, because I
think you're seeing a similar thing for less well maintained
filesystems.

I'd like to see us formulate a document we can put into the kernel and
point to when they come along. Probably formulated along the lines of
"first do no harm" and pointing out that every "fix" carries risk and
we have to set that risk against what we actually get in terms of
benefits. So require the submitter to specify:

 * What are the user visible effects (memory leak = none), transient
   bad stats data, or actual data corruption or kernel crash (latter
   being most serious)
 * how likely (or often) will this be seen?  If about once a kernel boot(
   or less), at this point if you have anything less than corruption or
   a crash, don't bother fixing it because the effect is too minor
 * For bad stats data, is there an existing tool that uses the data, if
   not don't bother and even if so show it leads to issues
 * How was the fix tested (to reduce risk) i.e. do you have the
   hardware or an acceptable emulation?  If not, report the issue, but
   don't bother sending the fix.

I think this is just a starting point, and, obviously, it's a bit
driver centric, but we can probably add generalizations for filesystems
(and even mm and bpf).

Regards,

James

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Bart Van Assche]

On 2/5/26 1:51 AM, James Bottomley wrote:
> I'm not even sure they're all AI found [...]

Some people use the checkpatch output or scripts from
scripts/coccinelle/ to create patches (I don't do this).

> I'd like to see us formulate a document we can put into the kernel and
> point to when they come along. Probably formulated along the lines of
> "first do no harm" and pointing out that every "fix" carries risk and
> we have to set that risk against what we actually get in terms of
> benefits. So require the submitter to specify:
> 
>   * What are the user visible effects (memory leak = none), transient
>     bad stats data, or actual data corruption or kernel crash (latter
>     being most serious)
>   * how likely (or often) will this be seen?  If about once a kernel boot(
>     or less), at this point if you have anything less than corruption or
>     a crash, don't bother fixing it because the effect is too minor
>   * For bad stats data, is there an existing tool that uses the data, if
>     not don't bother and even if so show it leads to issues
>   * How was the fix tested (to reduce risk) i.e. do you have the
>     hardware or an acceptable emulation?  If not, report the issue, but
>     don't bother sending the fix.
> 
> I think this is just a starting point, and, obviously, it's a bit
> driver centric, but we can probably add generalizations for filesystems
> (and even mm and bpf).

We don't want to forbid tree-wide API changes, isn't it? See also
Documentation/process/stable-api-nonsense.rst.

Sometimes I post patches myself that only have been compile-tested. 
These patches could help with deciding where to draw the line. A few
examples:
* [PATCH] scsi: mpt3sas: Simplify the workqueue allocation code,
   January 2026
  
(https://lore.kernel.org/linux-scsi/20260106185655.2526800-1-bvanassche@acm.org/).
* [PATCH 0/2] Fix locking bugs in error paths, February 2025
(https://lore.kernel.org/linux-scsi/20250210203936.2946494-1-bvanassche@acm.org/)

Thanks,

Bart.

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Matthew Wilcox]

On Thu, Feb 05, 2026 at 08:30:53AM -0800, Bart Van Assche wrote:
> We don't want to forbid tree-wide API changes, isn't it? See also
> Documentation/process/stable-api-nonsense.rst.

That's plainly not what James was talking about.  Tree-wide API changes
have an obvious benefit (... or if not, they'll be rejected).  The
question is what benefit does anyone receive from fixing an unlikely
memory leak in the ncr53c8xx driver?

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[James Bottomley]

On Thu, 2026-02-05 at 20:54 +0000, Matthew Wilcox wrote:
> On Thu, Feb 05, 2026 at 08:30:53AM -0800, Bart Van Assche wrote:
> > We don't want to forbid tree-wide API changes, isn't it? See also
> > Documentation/process/stable-api-nonsense.rst.
> 
> That's plainly not what James was talking about.  Tree-wide API
> changes have an obvious benefit (... or if not, they'll be
> rejected).  The question is what benefit does anyone receive from
> fixing an unlikely memory leak in the ncr53c8xx driver?

Well, even for API changes it wouldn't be unreasonable to do a cost
benefit analysis, but, as Matthew said, they're clearly not fixes.

Regards,

James

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Haris Iqbal]

On Thu, Feb 5, 2026 at 10:52 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> To set the stage, we in SCSI have seen an uptick in patches to older
> drivers mostly fixing missing free (data leak) and data race problems.
> I'm not even sure they're all AI found, but we don't really need to
> know that. The problem, that the submitters often don't appreciate, is
> that every "fix" has some chance of being wrong, so it requires code
> inspection (which is also not free, and which may get it wrong too) and
> testing, for which, often, no-one has any immediate hardware. The
> problems we see is that missed frees (often in error legs) represent
> tiny amounts of memory over the lifetime of the driver (they're often
> in the remove legs) and so we have to ask set against the risk of a
> wrong patch, is the problem even worth fixing? The same goes for data
> races ... and here the suggested fixes are often somewhat complex and,
> on analysis, problematic in some way. I've cc'd fsdevel, because I
> think you're seeing a similar thing for less well maintained
> filesystems.
>
> I'd like to see us formulate a document we can put into the kernel and
> point to when they come along. Probably formulated along the lines of
> "first do no harm" and pointing out that every "fix" carries risk and
> we have to set that risk against what we actually get in terms of
> benefits. So require the submitter to specify:
>
>  * What are the user visible effects (memory leak = none), transient
>    bad stats data, or actual data corruption or kernel crash (latter
>    being most serious)
>  * how likely (or often) will this be seen?  If about once a kernel boot(
>    or less), at this point if you have anything less than corruption or
>    a crash, don't bother fixing it because the effect is too minor
>  * For bad stats data, is there an existing tool that uses the data, if
>    not don't bother and even if so show it leads to issues
>  * How was the fix tested (to reduce risk) i.e. do you have the
>    hardware or an acceptable emulation?  If not, report the issue, but
>    don't bother sending the fix.
>
> I think this is just a starting point, and, obviously, it's a bit
> driver centric, but we can probably add generalizations for filesystems
> (and even mm and bpf).

It is an interesting proposal, but I feel the problem statement
overlaps with some other, already being discussed, or covered topics.
For example, the topic of fixes requiring effort and time of the
maintainer/reviewer, and the fact that AI now potentially leads to too
many such fixes is being discussed in the following link,

https://lore.kernel.org/ksummit/20251114183528.1239900-1-dave.hansen@linux.intel.com/#t

TL;DR
The submitter has to mention the tools used to generate the fix.
And the maintainer can choose how to handle fixes from certain tools,

+As with all contributions, individual maintainers have discretion to
+choose how they handle the contribution. For example, they might:
+
+ - Treat it just like any other contribution.
+ - Reject it outright.
+ - Treat the contribution specially like reviewing with extra scrutiny,
+   or at a lower priority than human-generated content
+ - Suggest a better prompt instead of suggesting specific code changes.
+ - Ask for some other special steps, like asking the contributor to
+   elaborate on how the tool or model was trained.
+ - Ask the submitter to explain in more detail about the contribution
+   so that the maintainer can feel comfortable that the submitter fully
+   understands how the code works.

The topic of how big are the effects, or how likely (or often) the
effects happens may just be linked to the main and IMHO an important
topic; availability of the hardware for testing.
For this too, the previous discussion explicitly asks the submitter
for the following,

+ - How is the submission tested and tools used to test the fix?

I am not sure if this discussion can be linked to the above mentioned
one, but there are definitely parallels here.

>
> Regards,
>
> James
>
>

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[James Bottomley]

On Thu, 2026-02-05 at 17:40 +0100, Haris Iqbal wrote:
[...]
> It is an interesting proposal, but I feel the problem statement
> overlaps with some other, already being discussed, or covered topics.
> For example, the topic of fixes requiring effort and time of the
> maintainer/reviewer, and the fact that AI now potentially leads to
> too many such fixes is being discussed in the following link,
> 
> https://lore.kernel.org/ksummit/20251114183528.1239900-1-dave.hansen@linux.intel.com/#t

They are actually pretty orthogonal.  The email is about identifying AI
tools used in submission.  I may suspect the uptick in the fixes is due
to the use of AI, but I don't really care.  The problem isn't what tool
you used it's that the risk vs benefit of actually fixing the driver
isn't favourable.

Regards,

James

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Chuck Lever]

Hello James,

On Thu, Feb 5, 2026, at 5:40 PM, James Bottomley wrote:
> On Thu, 2026-02-05 at 17:40 +0100, Haris Iqbal wrote:
> [...]
>> It is an interesting proposal, but I feel the problem statement
>> overlaps with some other, already being discussed, or covered topics.
>> For example, the topic of fixes requiring effort and time of the
>> maintainer/reviewer, and the fact that AI now potentially leads to
>> too many such fixes is being discussed in the following link,
>> 
>> https://lore.kernel.org/ksummit/20251114183528.1239900-1-dave.hansen@linux.intel.com/#t
>
> They are actually pretty orthogonal.  The email is about identifying AI
> tools used in submission.  I may suspect the uptick in the fixes is due
> to the use of AI, but I don't really care.  The problem isn't what tool
> you used it's that the risk vs benefit of actually fixing the driver
> isn't favourable.

Agreed, the fire hose of patches that a maintainer has to deal with
is a perennial problem, no matter the source of the patches.

Seems to me that benefits/cost analysis is part of patch review. But
when using AI for review, you can ask it to do an initial analysis
for you, rather than legislating contributor behavior (over which you
have no control).


-- 
Chuck Lever

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Finn Thain]

On Thu, 5 Feb 2026, James Bottomley wrote:

> To set the stage, we in SCSI have seen an uptick in patches to older
> drivers mostly fixing missing free (data leak) and data race problems.
> I'm not even sure they're all AI found, but we don't really need to
> know that. 

If I may predict the next scene, by extrapolating only a little, we are 
approaching the point where it will be feasible to request that an AI 
simply generate a new driver, based on chip datasheets plus all of the 
open source drivers available for training, rather than patch the bugs in 
an existing driver.

At that point, what use is a maintainer? I think we can still add value if 
we are able to leverage our ability and experience in validating such code 
i.e. prove its correctness somehow. If we can do that, then the codebase 
we presently call Linux might continue to grow because it would remain 
superior than some AI-generated alternative codebase.

Documentation that would raise the bar for patch submissions seems like a 
band-aid. The basic complaint seems to be that minor fixes have become 
cheaper and easier to produce, overwhelming reviewers. The solution has to 
be, make code review cheaper and more effective i.e. fight fire with fire.

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Darrick J. Wong]

On Fri, Feb 06, 2026 at 09:57:45AM +1100, Finn Thain wrote:
> 
> On Thu, 5 Feb 2026, James Bottomley wrote:
> 
> > To set the stage, we in SCSI have seen an uptick in patches to older
> > drivers mostly fixing missing free (data leak) and data race problems.
> > I'm not even sure they're all AI found, but we don't really need to
> > know that. 
> 
> If I may predict the next scene, by extrapolating only a little, we are 
> approaching the point where it will be feasible to request that an AI 
> simply generate a new driver, based on chip datasheets plus all of the 
> open source drivers available for training, rather than patch the bugs in 
> an existing driver.
> 
> At that point, what use is a maintainer? I think we can still add value if 

Being a magic sources of datasheets obtained through murky means,
obviously.  What /was/ grandpa doing when he came home with a bunch of
weird machinery at 3am in 1957??  :P

--D

> we are able to leverage our ability and experience in validating such code 
> i.e. prove its correctness somehow. If we can do that, then the codebase 
> we presently call Linux might continue to grow because it would remain 
> superior than some AI-generated alternative codebase.
> 
> Documentation that would raise the bar for patch submissions seems like a 
> band-aid. The basic complaint seems to be that minor fixes have become 
> cheaper and easier to produce, overwhelming reviewers. The solution has to 
> be, make code review cheaper and more effective i.e. fight fire with fire.
> 

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Finn Thain]

On Thu, 5 Feb 2026, Darrick J. Wong wrote:

> On Fri, Feb 06, 2026 at 09:57:45AM +1100, Finn Thain wrote:
> > 
> > On Thu, 5 Feb 2026, James Bottomley wrote:
> > 
> > > To set the stage, we in SCSI have seen an uptick in patches to older 
> > > drivers mostly fixing missing free (data leak) and data race 
> > > problems. I'm not even sure they're all AI found, but we don't 
> > > really need to know that.
> > 
> > If I may predict the next scene, by extrapolating only a little, we 
> > are approaching the point where it will be feasible to request that an 
> > AI simply generate a new driver, based on chip datasheets plus all of 
> > the open source drivers available for training, rather than patch the 
> > bugs in an existing driver.
> > 
> > At that point, what use is a maintainer? I think we can still add 
> > value if
> 
> Being a magic sources of datasheets obtained through murky means, 
> obviously.  What /was/ grandpa doing when he came home with a bunch of 
> weird machinery at 3am in 1957??  :P
> 

I'm told he was building a steam-powered flying saucer. I don't know 
whether he was more interested in the question, how did we get here or to 
where might we go.

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[James Bottomley]

On Fri, 2026-02-06 at 09:57 +1100, Finn Thain wrote:
> 
> On Thu, 5 Feb 2026, James Bottomley wrote:
> 
> > To set the stage, we in SCSI have seen an uptick in patches to
> > older drivers mostly fixing missing free (data leak) and data race
> > problems. I'm not even sure they're all AI found, but we don't
> > really need to know that. 
> 
> If I may predict the next scene, by extrapolating only a little, we
> are approaching the point where it will be feasible to request that
> an AI simply generate a new driver, based on chip datasheets plus all
> of the open source drivers available for training, rather than patch 
> the bugs in an existing driver.

Seems possible, but do we care?  For a driver we don't have, I think
we'd be reasonably happy to try out an AI generated one, assuming
there's a maintainer who has hardware to test.  For existing drivers, I
think AI rewrites (even in rust) would be rejected.

> At that point, what use is a maintainer? I think we can still add
> value if we are able to leverage our ability and experience in
> validating such code  i.e. prove its correctness somehow. If we can
> do that, then the codebase we presently call Linux might continue to
> grow because it would remain superior than some AI-generated
> alternative codebase.

Well, I don't think regarding Maintainers as being in competition with
AI will be very productive.  AI is a tool for maintainers to use, if
they wish, to augment their other skills.

> Documentation that would raise the bar for patch submissions seems
> like a band-aid. The basic complaint seems to be that minor fixes
> have become cheaper and easier to produce, overwhelming reviewers.
> The solution has to be, make code review cheaper and more effective
> i.e. fight fire with fire.

Chris Mason is already doing that, I think.  However, I didn't anchor
my proposal around lack of review, I anchored it to a better documented
risk/benefit calculation ... and that doesn't change enormously however
many reviews the patch gets.

Regards,

James

Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

[Finn Thain]

On Sun, 8 Feb 2026, James Bottomley wrote:

> On Fri, 2026-02-06 at 09:57 +1100, Finn Thain wrote:
> > 
> > On Thu, 5 Feb 2026, James Bottomley wrote:
> > 
> > > To set the stage, we in SCSI have seen an uptick in patches to older 
> > > drivers mostly fixing missing free (data leak) and data race 
> > > problems. I'm not even sure they're all AI found, but we don't 
> > > really need to know that.
> > 
> > If I may predict the next scene, by extrapolating only a little, we 
> > are approaching the point where it will be feasible to request that an 
> > AI simply generate a new driver, based on chip datasheets plus all of 
> > the open source drivers available for training, rather than patch the 
> > bugs in an existing driver.
> 
> Seems possible, but do we care?  For a driver we don't have, I think 
> we'd be reasonably happy to try out an AI generated one, assuming 
> there's a maintainer who has hardware to test.  For existing drivers, I 
> think AI rewrites (even in rust) would be rejected.
> 

My hope is that, one day, rewrites would get accepted or rejected on the 
basis of correctness, fitness for purpose, conformance to specification, 
auditability and those user expectations which the Linux project upholds. 
The maintainer's power of veto comes with a duty to attend to those 
things.

Any code which makes the grade could then get called "Linux" regardless of 
whether it was hand-coded last century or generated by machine on demand 
in whatever language best suits the algorithm at hand and the reader's 
personal taste.

> > At that point, what use is a maintainer? I think we can still add 
> > value if we are able to leverage our ability and experience in 
> > validating such code i.e. prove its correctness somehow. If we can do 
> > that, then the codebase we presently call Linux might continue to grow 
> > because it would remain superior than some AI-generated alternative 
> > codebase.
> 
> Well, I don't think regarding Maintainers as being in competition with 
> AI will be very productive.  AI is a tool for maintainers to use, if 
> they wish, to augment their other skills.
> 

OK, but then we must quit competing, and let the tools do those things 
that they do best.

Perhaps I'm being too optimistic -- even though we've had clang-format for 
years, every week I see reviewers checking code style. If reviewers can't 
collaborate and automate that problem away, what hope is there for 
automatic proof checking?

> > Documentation that would raise the bar for patch submissions seems 
> > like a band-aid. The basic complaint seems to be that minor fixes have 
> > become cheaper and easier to produce, overwhelming reviewers. The 
> > solution has to be, make code review cheaper and more effective i.e. 
> > fight fire with fire.
> 
> Chris Mason is already doing that, I think.  However, I didn't anchor my 
> proposal around lack of review, I anchored it to a better documented 
> risk/benefit calculation ... and that doesn't change enormously however 
> many reviews the patch gets.
> 

Yes, on the cost side of the ledger, code review has to be made cheaper 
somehow.

On the benefit side, I think the payoff from fixing theoretical 
correctness bugs is an unknown quantity. For example, it seems likely that 
by defending against hostile hardware, you'd end up with a device driver 
that's much more amenable to a correctness proof than a driver whose 
entire behaviour is a function of hardware timing quirks.

The cost of ignoring minor theoretical correctness fixes is also an 
unknown quantity. But I think it must increase as the tooling becomes more 
capable and more widely deployed. If the tooling is constantly complaining 
about those defects, this would add friction for all tree-wide analysis or 
refactoring.