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

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:

quoted

From: Ramses de Norre <redacted>

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 <redacted>

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