Re: [Linuxptp-devel] [PATCH v2 2/3] clock: dump unexpected packets received on the error queues of
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Vladimir O. <ol...@gm...> - 2020-06-24 16:37:06
|
Hi Richard, On Wed, 24 Jun 2020 at 19:27, Richard Cochran <ric...@gm...> 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 <ol...@gm...> > Signed-off-by: Richard Cochran <ric...@gm...> > > Thoughts? -Vladimir |