Hi Richard, On Wed, 24 Jun 2020 at 19:27, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Fri, Jun 19, 2020 at 10:45:23PM +0300, Vladimir Oltean wrote: > > Yes, much better. > > May I add your tag to the commit message, like this?
I think the commit description is slightly lossy and a bit misleading. > > Catch unexpected socket polling errors. This part is ok. > > The poll(2) system call may set POLLERR in the returned events. Normally > no errors are returned unless specifically requested by setting an > appropriate socket option. Socket option which _is_ set, that's how we get our TX timestamps, not sure why you see the need to mention this. > Nevertheless, the poll(2) API is quite generic, > and there is no guarantee that the kernel networking stack might push an > error event one day. This patch adds defensive code in order to catch any > unexpected error condition. > I am reading this as: "let's be defensive even in the case where the kernel decides to go nuts and push us a packet on the error queue even if we didn't enable SO_SELECT_ERR_QUEUE". But that isn't at all what's going on. As stated, we opted in this SO_SELECT_ERR_QUEUE game because we need TX timestamps. So we need to be correct, and play by the API's rules, which means treat the POLLERR returned event. It is a correctness issue, not a defense issue. > Suggested-by: Vladimir Oltean <olte...@gmail.com> > Signed-off-by: Richard Cochran <richardcoch...@gmail.com> > > Thoughts? -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel