Thank you @liujinhui-job.

Could you share your (minimal) repro please? The latest incarnation appears correct to me, but my concern is that the affected code has not been updated recently, and there may be additional regressions lurking in the area, rendering this fix incomplete.

I can reproduce it with tx_timestamping, but it requires some hacking in pkt_filler to reduce the delta between buf_start and buf_end from 2048 to a smaller number, e.g. ~1000, combined with a larger payload size, e.g. ~1500, sent by the client app:

$ scripts/onload build/gnu_x86_64/tests/onload/hwtimestamping/tx_timestamping --proto tcp --templated
...
TCP listening on port 9000
 TCP connection accepted
Selecting hardware timestamping mode.
...
Packet 0 - 1528 bytes
Segmentation fault (core dumped)

In other words, I'm not convinced my repro is good enough to verify your fix.

While examining the source code, I observed that the parameter "NULL/p_netif_locked/" appeared unusual.

Consequently, I modified the ts->eff_mss value in the ci_tcp_send_fill_pkts function to 4096 and transmitted a 4096-byte packet, which successfully triggered a segmentation fault.

However, in actual operational scenarios, I'm uncertain whether ts->eff_mss would realistically reach 4096.

I wonder if we are looking at dead code in oo_pkt_fill() and should replace if( pf->buf_start == pf->buf_end ) with assert( pf->buf_start != pf->buf_end ). I cannot say now without further looking at the code and various NIC constraints.