Re: [Linuxptp-devel] [PATCH v2 2/3] clock: dump unexpected packets received on the error queues of sockets

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Richard Cochran <ric...@gm...>
> Sent: Wednesday, June 24, 2020 9:58 AM
> To: Vladimir Oltean <ol...@gm...>
> Cc: lin...@li...; Keller, Jacob E
> <jac...@in...>
> Subject: Re: [PATCH v2 2/3] clock: dump unexpected packets received on the
> error queues of sockets
> 
> On Wed, Jun 24, 2020 at 07:36:47PM +0300, Vladimir Oltean wrote:
> > 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.
> 
> But, at this point in the program, we know that no tx time stamp is
> outstanding.  We always send one Tx event, then immediately fetch the
> time stamp.  This is carefully synchronized by the program.  It is
> important to do this because many drivers support exactly one Tx time
> stamp at a time.
> 
> The kernel must not fabricate transmit time stamps!  That would be
> breaking the contract.

Sure, but the POLLERR could (in theory, not in current practice) return other events/messages besides timestamps.

It was invented/created prior to the Tx timestamps, wasn't it?

> 
> > 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.
> 
> I think you are splitting hairs here, but I disagree that the program
> was incorrect.  There is no reason _today_ for poll to return a
> POLLERR event from this call, but, in general, I don't believe this is
> guaranteed by anything.
> 

Right. Today there's no other messages that I am aware of.

> Would you prefer me leaving your name off the commit message?
> 
> Thanks,
> Richard
> 
>