Re: [PATCH net] net/mlx5e: Fix NULL deref in PTP TX timestamp recovery warn

[Paolo Abeni <pabeni@redhat.com>]

On 10/15/26 11:37, Carolina Jubran wrote:
> On 15/10/2026 11:09, netdev-bot+sinfo@kernel.org wrote:
>> 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.
>>
>> 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,
> 
> The issue was observed during our internal regression testing.
> 
> The kernel reported:
> 
> BUG: unable to handle page fault for address: 0000000000002ea8
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 1a9bfc067 P4D 1a9bfc067 PUD 1a9bfd067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           OE
> RIP: 0010:mlx5e_skb_cb_hwtstamp_handler+0x10c/0x140 [mlx5_core]
> RAX: 0000000000000000
> CR2: 0000000000002ea8
> Call Trace:
>    mlx5e_ptp_poll_ts_cq+0x228/0x5b0 [mlx5_core]
>    mlx5e_ptp_napi_poll+0xad/0x380 [mlx5_core]
>    ? mlx5e_napi_poll+0x750/0x7e0 [mlx5_core]
>    __napi_poll+0x30/0x200
>    net_rx_action+0x181/0x2e0
>    handle_softirqs+0xdb/0x340
>    __irq_exit_rcu+0xd9/0x100
>    irq_exit_rcu+0xe/0x20
>    common_interrupt+0xa4/0xb0
> 
> So far, the issue has only been observed during our regression testing,
> and I am still working on reproducing it reliably.
For future patches please include such kind of info (specifically: the
backtrace) in the commit message itself.

Thanks,

Paolo