Re: [PATCH net] wireguard: queueing: preserve tstamp_type in wg_reset_packet()

[Ramses <ramses@well-founded.dev>]

Aug 31, 2026, 05:25 by Jason@zx2c4.com:

> Hi Ramses,
>
> On Thu, Aug 27, 2026 at 01:52:56PM +0200, Ramses de Norre via B4 Relay wrote:
>
>> From: Ramses de Norre <ramses@well-founded.dev>
>>
>> Sending traffic through a wireguard tunnel on a host using the fq
>> qdisc fills the log with:
>>
>>  fq: likely mono tstamp with tstamp_type 0
>>
>> An skb carries a timestamp in skb->tstamp and, separately, a
>> skb->tstamp_type field recording which clock that timestamp came from.
>> The two have to agree.
>>
>> When wireguard encapsulates a packet it calls wg_reset_packet(), which
>> clears the fields that must not leak from the inner packet into the
>> tunnel packet. It does so in two steps:
>>
>>  skb_scrub_packet(skb, true);
>>  memset(&skb->headers, 0, sizeof(skb->headers));
>>
>> skb_scrub_packet() deliberately keeps skb->tstamp when it holds a
>> monotonic timestamp: that value is the time the packet is scheduled to
>> be sent, and the qdisc still needs it. The memset then zeroes
>> skb->tstamp_type, because that field sits inside the headers group
>> while skb->tstamp does not. The packet therefore leaves wireguard
>> carrying a monotonic timestamp labelled as a realtime one.
>>
>> Nothing noticed until commit c4f796c4f16b ("net_sched: sch_fq: convert
>> skb->tstamp if not monotonic"): fq used to assume every timestamp was
>> monotonic. It now consults tstamp_type, spots the mismatch, warns, and
>> falls back to treating the value as monotonic. Pacing still ends up
>> correct, so the log spam is the actual problem.
>>
>> Save tstamp_type before the memset and restore it when encapsulating,
>> next to the hash fields that are already carried over this way. When
>> decapsulating it stays zeroed, which is right: an incoming packet's
>> timestamp is a realtime receive timestamp.
>>
>> Fixes: de799101519a ("net: Add skb_clear_tstamp() to keep the mono delivery_time")
>> Signed-off-by: Ramses de Norre <ramses@well-founded.dev>
>>
>
> Thanks for this. I've queued this up in the wireguard tree.
>
> One thing I'm wondering is whether your Fixes: line is correct. Would
> c4f796c4f16b be a better candidate than de799101519a? Or maybe even
> 4d25ca2d6801 is best?
>
> Jason
>
Hi Jason

I think you are right, but I think d98d58a00261 is actually the commit that introduced the issue then (but no warnings were logged yet at that point).
The patch doesn't apply cleanly to that version though, I think it only applies starting from 6.11 because of a rename, so we can't backport all the way back. It's probably fine though, since the warnings weren't being logged yet at that point.
Do you want me to send an updated patch, or will you just fix this up in your tree?

Thanks,
Ramses