jnippula commented on PR #17304: URL: https://github.com/apache/nuttx/pull/17304#issuecomment-3515546374
> Even if we do not release d_iob in devif_poll, when we return to tcp_alloc_accept, the content of d_iob has already changed, and at this time, some of the values assigned to accept conn should be incorrect. Correct me if I'm wrong, but in my understanding in this case the content of the d_iob is not changed after devif_poll, because the connection being accepted is not yet in the g_active_tcp_connections pool, so the devif_poll can't find anything that would match the condition "if (dev == conn->dev)" (because tcp_alloc_accept fills that info after the tcp_alloc has returned and netlock is already restored). So, I don't see any benefit or good reason why the drv->d_iob should be released in the devif_poll, if it does not find anything to do with that iob, as it is not linked to any connection. If the buffer is consumed by the devif_poll (according to bstop) then the iob content is changed and shall also be released. > Moreover, for the old network card drivers that do not use d_iob for packet transmission, not clearing d_iob after the interface returns will cause exceptions in subsequent processes The iob releasing of the flat buffer case is not touched. The flat buffer case is different, because the iob is only temporarily used and the content is explicitly copied from iob to flat buffer. The data is safe and accessible after the devif_poll. If the devif_poll would periodically unconditionally just clean up d_iob from all drivers even there is nothing to be done (yet), I see a risk that some later implementation utilizing timed wait would face this kind of race condition again. -- 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]
