On Tue, 10 Mar 2026 08:05:39 +0200 Mark Bloch wrote:

On 09/03/2026 23:33, Jakub Kicinski wrote:

quoted

On Sun, 8 Mar 2026 20:34:26 +0200 Mark Bloch wrote:  

quoted

Thanks for catching this. We’ll address it.

Also, I saw IA flagged issues con
“net/mlx5: LAG, replace pf array with xarray”.
Just for context, lag_lock is already a known problematic
area for us, and we do have plans to remove it. I ran the
review prompts locally in ORC mode, so I assume I saw the
same comments as NIPA.

So the issue raised there is not really a new one. lag_lock
already has some known issues today, but we do not expect to
hit this particular case in practice, since by the time
execution reaches mdev removal, the LAG should already have
been destroyed and the netdevs already removed for the driver
internal structures.  

Ack, I haven't looked at the AI reivew TBH.
As usual with known AI flags - should the explanation be part 
of the commit message?  

That's an interesting question.
I'll try to give my 0.02$ about the general case.
Out of curiosity I ran one of our upcoming internal series
through both Mason's prompts with Claude and our internal
AI review tool.

Mason's + Claude reported 3 false positives.

Our internal AI tool also reported 3 false positives (interestingly,
they were different issues) and 1 real issue, which I already knew
about since the author hasn't fixed it yet.

So in theory we could add a note like “AI tools may flag issues
X/Y/Z but those are not valid here”, but in practice it really
depends on which tool is used and how it's configured.

At the moment it seems that netdev/NIPA is using Mason's prompts
with Claude, so if anything that would probably be the default
reference.

The larger question is that running NIPA before submission is
not currently required. Are there any plans to make that part
of the submission expectations, and not just encouraged?

No, no, the process angle is not how I look at this.
We should only add comments to the commit message or code if there's
genuine ambiguity. Basically if someone reading the code may also get
confused there should be an explanation somewhere. We should not be
adding any code or explanations to make tools happy.