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

Reply via email to