zhhyu7 commented on PR #17304: URL: https://github.com/apache/nuttx/pull/17304#issuecomment-3515896207
> 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. > devif_poll is a sending behavior initiated by other conn bound to this dev. During this sending process, the TCP_SYN packet received this time and saved in d_iob for initializing accpet conn may be overwritten. > 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. If we do not set d_iob to NULL before devif_poll returns, when the driver that passes data into the protocol stack through d_buf will trigger the dev->d_iob != NULL condition in the next call ipv4_input(and other xxx_input), the previous d_iob will be directly input into the protocol stack as a new packet. Obviously, this is unreasonable. -- 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]
