> >>>> static inline void skb_set_delivery_time(struct sk_buff *skb, ktime_t kt,
> >>>> - bool mono)
> >>>> + u8 tstamp_type)
> >>>> {
> >>>> skb->tstamp = kt;
> >>>> - skb->mono_delivery_time = kt && mono;
> >>>> +
> >>>> + switch (tstamp_type) {
> >>>> + case CLOCK_REAL:
> >>>> + skb->tstamp_type = CLOCK_REAL;
> >>>> + break;
> >>>> + case CLOCK_MONO:
> >>>> + skb->tstamp_type = kt && tstamp_type;
> >>>> + break;
> >>>> + }
> >>>
> >>> Technically this leaves the tstamp_type undefined if (skb, 0, CLOCK_REAL)
> >> Do you think i should be checking for valid value of tstamp before setting the tstamp_type ? Only then set it.
> >
> > A kt of 0 is interpreted as resetting the type. That should probably
> > be maintained.
> >
> > For SO_TIMESTAMPING, a mono delivery time of 0 does have some meaning.
> > In __sock_recv_timestamp:
> >
> > /* Race occurred between timestamp enabling and packet
> > receiving. Fill in the current time for now. */
> > if (need_software_tstamp && skb->tstamp == 0) {
> > __net_timestamp(skb);
> > false_tstamp = 1;
> > }
>
> Well in that case the above logic still resets the tstamp and sets the tstamp_type to CLOCK_REAL(value 0).
> Anyway the tstamp_type will be 0 to begin with.
> The logic is still inline with previous implementation, because previously if kt was 0 then kt && mono sets the tstamp_type (previously called as mono_delivery_time) to 0 (i.e SKB_CLOCK_REAL).
Sorry, I got my defaults confused. If we maintain that a zero tstamp
resets the type, then here should be no case with skb->tstamp 0 and
skb->tstamp_type SKB_CLOCK_REAL (or SKB_CLOCK_TAI or whatever). I
think it's preferable to make that obvious in the
skb_set_delivery_time implementation, rather than depend on knowledge
of its callers.
