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

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

[Ramses de Norre via B4 Relay]

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>
---
 drivers/net/wireguard/queueing.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 79b6d70de236b..663b19b783953 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -78,12 +78,14 @@ static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating)
 	u8 l4_hash = skb->l4_hash;
 	u8 sw_hash = skb->sw_hash;
 	u32 hash = skb->hash;
+	u8 tstamp_type = skb->tstamp_type;
 	skb_scrub_packet(skb, true);
 	memset(&skb->headers, 0, sizeof(skb->headers));
 	if (encapsulating) {
 		skb->l4_hash = l4_hash;
 		skb->sw_hash = sw_hash;
 		skb->hash = hash;
+		skb->tstamp_type = tstamp_type;
 	}
 	skb->queue_mapping = 0;
 	skb->nohdr = 0;

---
base-commit: 24ef02f934eeb48830cff6b739abc3c62b1d107b
change-id: 20260817-wg-tstamp-b327825122dc

Best regards,
--  
Ramses de Norre <ramses@well-founded.dev>

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

[Toke Høiland-Jørgensen]

Ramses de Norre via B4 Relay
<devnull+ramses.well-founded.dev@kernel.org> writes:

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

Seems reasonable:

Reviewed-by: Toke Høiland-Jørgensen <toke@kernel.org>

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

[Eric Dumazet]

On Thu, Aug 27, 2026 at 3:28 PM Toke Høiland-Jørgensen <toke@kernel.org> wrote:
>
> Ramses de Norre via B4 Relay
> <devnull+ramses.well-founded.dev@kernel.org> writes:
>
> > 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>
>
> Seems reasonable:
>
> Reviewed-by: Toke Høiland-Jørgensen <toke@kernel.org>

Reviewed-by: Eric Dumazet <edumazet@google.com>

Thanks.

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

[Jason A. Donenfeld]

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>
> ---
>  drivers/net/wireguard/queueing.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
> index 79b6d70de236b..663b19b783953 100644
> --- a/drivers/net/wireguard/queueing.h
> +++ b/drivers/net/wireguard/queueing.h
> @@ -78,12 +78,14 @@ static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating)
>  	u8 l4_hash = skb->l4_hash;
>  	u8 sw_hash = skb->sw_hash;
>  	u32 hash = skb->hash;
> +	u8 tstamp_type = skb->tstamp_type;
>  	skb_scrub_packet(skb, true);
>  	memset(&skb->headers, 0, sizeof(skb->headers));
>  	if (encapsulating) {
>  		skb->l4_hash = l4_hash;
>  		skb->sw_hash = sw_hash;
>  		skb->hash = hash;
> +		skb->tstamp_type = tstamp_type;
>  	}
>  	skb->queue_mapping = 0;
>  	skb->nohdr = 0;

Seems reasonable to me. I'll put this through the paces testing and
queue it up when I'm back at my laptop on Monday.

Jason

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

[Jason A. Donenfeld]

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

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

[Ramses]

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