Re: [PATCH net] net/mlx5: retain command mailboxes after timeout

[manjunath.b.patil@oracle.com]

On 10/2/26 1:58 PM, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>   - How the issue was discovered, e.g. hit in production, hit during
>     development, syzbot report, manual code inspection, LLM or static
>     analysis tool scan.
> 
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
> 
>   - What hardware the change was tested on. For driver fixes please
>     mention the device (and if relevant firmware version) used for
>     testing, or say that the change was not tested on real hardware.
> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Hi,

Thanks for the reminder. This was prompted by crashes on two production
systems with mlx5 command timeouts and device-health errors. One log
reported "Command completion arrived after timeout (entry idx = 2)"
shortly before an oops:

   BUG: kernel NULL pointer dereference, address: 0000000000000100
   RIP: dma_pool_alloc+0x3b/0x211
   mlx5_alloc_cmd_msg -> cmd_exec -> mlx5e_update_stats_work

The vmcores showed the mlx5_cmd DMA pool's next_block pointer at 0x100.
Manual inspection of the command timeout path then identified the early
mailbox free addressed by this patch. The production failure is real, 
but we have not proved that late firmware access caused that particular 
pool corruption, nor reproduced the original panic.

I tested the fix on an OL9 x86_64 VM with two passthrough ConnectX-7
SR-IOV VFs, both reporting firmware 28.34.4000. Test-only fault 
injection exercised normal, timeout-late, timeout-reset, timeout-lost, 
and timeout/completion-overlap paths on both VFs. In the overlap test, 
the blocking caller returned -ETIMEDOUT while completion was paused 
before its final mailbox access; the mailboxes and slot remained live 
until completion finished, then were released. There were no KASAN 
reports or kmemleak findings. The overlap uses a synthetic sleepable 
completion worker, not a physical firmware EQ interrupt.

Thanks,
Manjunath