Hi Julian, Thanks for your review.
> On Jul 6, 2026, at 01:35, Julian Anastasov <[email protected]> wrote: > > May be it is better starting from ip_vs_set_state() > to provide new arg 'int iph_len/offset' (set to iph.len), down to > state_transition(), sctp_state_transition() and set_sctp_state(). > Same for all protos. It should cost less stack and ipv6_find_hdr() > calls and what matters most, correct iph context in case we > have IP+ICMP+TCP (with just two ports or even with TCP flags) > and are scheduling ICMP, i.e. not IP+TCP as usually. I agree that the already parsed transport-header offset should be passed from ip_vs_set_state() down to the protocol state_transition() callbacks, instead of reparsing the skb in set_sctp_state(). We will send a v2 that does this for SCTP, TCP and the other IPVS protocols in one combined fix. > But what I see is that ip_vs_in_icmp*() are missing > the ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd) call just > after ip_vs_in_stats() and before ip_vs_icmp_xmit() where > we should provide ciph.len. That is why we don't reach the > set_tcp_state() calls to set correct cp->state and timeout > when scheduling related ICMP. So, this should be fixed too. For the ICMP path, I agree that the missing ip_vs_set_state() call is worth looking at, but using ICMP errors to drive the upper L4 state needs some care, because spoofed ICMP packets can match an existing embedded tuple before the endpoint TCP/SCTP stack performs its own validation. Maybe this change needs further discussion? Thanks, Yizhou
