jerpelea opened a new pull request, #19628: URL: https://github.com/apache/nuttx/pull/19628
## Summary Two related defects corrupt CDC-NCM transmit once TCP write buffers make TX bursty (a single txavail poll drains many queued segments back-to-back through cdcncm_send): 1. Buffer-reuse race. cdcncm coalesces datagrams into the single pre-allocated wrreq->buf that the USB controller transmits directly from, but cdcncm_send formatted a new NTB batch into it (cdcncm_transmit_format) without first waiting for the previous transfer to complete -- the wrreq_idle wait happened only later, in cdcncm_transmit_work. A new batch started while the previous NTB was still in flight overwrote the in-flight buffer, so the host dropped the corrupted NTB and TX could wedge (wrreq_idle never reposted). Fix: acquire wrreq_idle in cdcncm_send when starting a new batch (dgramcount == 0), before formatting; drop the now-redundant wait in cdcncm_transmit_work (a second wait on the init-to-1 semaphore would deadlock). 2. Concurrent transmit_work. cdcncm_send runs under the recursive netdev_lock and calls cdcncm_transmit_work() synchronously in the buffer-full branch, while a scheduled delaywork instance runs cdcncm_transmit_work() on ETHWORK -- two different threads. Two EP_SUBMITs of the one wrreq corrupt the IN request queue and leave the IN buffer prepared-but-unarmed (controller idle, wrreq_idle never reposted). Fix: wrap cdcncm_transmit_work in netdev_lock (the synchronous caller already holds this recursive nxrmutex; a delaywork instance blocks until the drain releases it), and add an empty-batch guard (dgramcount == 0 -> return) so a delaywork that runs after a synchronous flush emptied the batch does not seal an empty NTB and double-submit the in-flight wrreq. Validated on RP2350 (Pico 2 W) with CONFIG_NET_TCP_WRITE_BUFFERS=y as part of the complete fix set: 144 dense/concurrent HTTP downloads, zero wedges, ~486 KB/s (previously transmit hung within a few requests). On RP2350 full stability under maximal TX density additionally requires a memory barrier between the BUFF_STATUS clear and the AVAILABLE re-arm in the Cortex-M33 USB device driver (a separate change); these cdcncm defects are real and the fixes correct independent of it. ## Impact RELEASE ## Testing CI -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
