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

[Bart Van Assche <bvanassche@acm.org>]

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.