> -----Original Message-----
> From: Vladimir Oltean <olte...@gmail.com>
> Sent: Tuesday, December 17, 2019 12:34 PM
> To: Keller, Jacob E <jacob.e.kel...@intel.com>
> Cc: richardcoch...@gmail.com; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH 2/3] clock: Dump unexpected packets
> received on the error queues of sockets
>
> On Tue, 17 Dec 2019 at 22:04, Keller, Jacob E <jacob.e.kel...@intel.com>
> wrote:
>
> > > -----Original Message-----
> > > From: Vladimir Oltean <olte...@gmail.com>
> > > Sent: Monday, December 16, 2019 3:11 PM
> > > To: richardcoch...@gmail.com
> > > Cc: linuxptp-devel@lists.sourceforge.net
> > > Subject: [Linuxptp-devel] [PATCH 2/3] clock: Dump unexpected packets
> received
> > > on the error queues of sockets
> > > For messages that the application does not / no longer expects, such as
> > > TX timestamps delivered late, duplicate TX timestamps, general
> > > exceptional messages enqueued by the kernel in the socket error queue
> > > etc, ptp4l will be taken by surprise in clock_poll() by these, and will
> > > think that there is data, since POLLIN is set (but in fact in the socket
> > > error queue etc, ptp4l will be taken by surprise in clock_poll() by
> > > these, and will think that there is data, since POLLIN is set (but in
> > > fact POLLERR is also set, and this has an entirely different meaning).
> >
> > This double parenthetical is a bit hard to parse.
> >
>
> Sorry, this is hard for me to understand too. The paragraph should have been:
>
> For messages that the application does not / no longer expects, such as
> TX timestamps delivered late, duplicate TX timestamps, general
> exceptional messages enqueued by the kernel in the socket error queue
> etc, ptp4l will be taken by surprise in clock_poll() by these, and will
> think that there is data, since POLLIN is set (but in fact POLLERR is
> also set, and this has an entirely different meaning), and will attempt
> to dequeue them from the wrong queue, which is empty.
>
That sounds better. It still feels a bit like a run-on sentence. Maybe
something like:
For messages that the application does not / no longer expects, such as Tx
timestamps delivered late, duplicate Tx timestamps, or general exceptional
messages enqueued by the kernel in the socket error queue, ptp4l will be taken
by surprise in clock_poll(). It will think there is data, since POLLIN is set.
In fact, POLLERR is also set which gives an entirely different meaning. Because
of this, ptp4l will attempt to dequeue messages from the wrong (empty) queue.
>
> > >
> > > A very, very simple reproducer is to take a DSA switch and run:
> > >
> > > tcpdump -i eth0 -j adapter_unsynced
> > >
> > > on its DSA master net device. The above command will enable timestamping
> > > on that net device, and if both the DSA switch and the master support
> > > PTP, this will make the kernel send duplicate TX timestamps for every
> > > sent event packet, which will completely kill ptp4l until a reboot, with
> > > no indication whatsoever of what's going on.
> > >
> > > Since the messages on the error queue are unexpected, we have no need
> > > for them. And they can be in theory anything, so simply hex dumping
> > > their content and moving along sounds like a good idea.
> > >
> > > Printing them to the user is optional (and helpful), but reading them is
> > > not. With this patch, even with extraneous data delivered by a buggy
> > > kernel (which the application now loudly complains about), the
> > > synchronization keeps chugging along. Otherwise the application starts
> > > reordering packets in recvmsg() due to misinterpreting which socket
> > > queue has data available.
> > >
> > > Signed-off-by: Vladimir Oltean <olte...@gmail.com>
> > > ---
> > > clock.c | 11 +++++++++++
> > > msg.c | 12 ++++++++++++
> > > msg.h | 7 +++++++
> > > 3 files changed, 30 insertions(+)
> > >
> > > diff --git a/clock.c b/clock.c
> > > index 146576ac589c..768bbb49513d 100644
> > > --- a/clock.c
> > > +++ b/clock.c
> > > @@ -1508,6 +1508,17 @@ int clock_poll(struct clock *c)
> > > LIST_FOREACH(p, &c->ports, list) {
> > > /* Let the ports handle their events. */
> > > for (i = 0; i < N_POLLFD; i++) {
> > > + if (cur[i].revents & POLLERR) {
> > > + unsigned char pkt[1600];
> > > +
> > > + cnt = recv(cur[i].fd, pkt, sizeof(pkt),
> > > + MSG_ERRQUEUE);
> > > + pr_err("Unexpected data on socket err
> > > queue:");
> > > + msg_raw_dump(pkt, cnt);
> > > +
> > > + continue;
> > > + }
> > > +
> >
> > Does it makes sense to always print these at pr_err level? I suppose we
> > almost
> never expect messages besides Tx timestamps, so warning loudly is better than
> only warning if you enable the higher debug printing.. However.. with this
> change
> it almost feels like these are now ignored/handled properly and thus not an
> issue
> so printing them at like pr_debug might make more sense?
>
> For my particular case, this is dead code because of the kernel fix.
> The other "[PATCH 3/3] port: Signal sync/follow-up mismatch events
> loudly" is dead code because of this one.
Right. This only matters in the case where we *do* get extra messages.
>
> For anybody else, I suppose that this is the beginning of the end of
> what ptp4l will tell them anyway. So I'm not too concerned that it's
> too loud. It isn't guarded by anything else, it is the other way
> around. First you poll on the fd, then you recvmsg and process it to
> see what it is.
I'm just wanting to make sure that the messages aren't going to be something
where "things work as expected, and now the user is confused by the additional
messages".
It sounds like this should be rare enough that always dumping and loudly
complaining is the right thing to do.
Thanks,
Jake
>
> >
> > Hmm. I think I'm fine with this either way.
> >
> > Thanks,
> > Jake
>
> Thanks,
> -Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
