Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: - [Critical] Replacing NETIF_F_IPV6_CSUM with NETIF_F_HW_CSUM bypasses the kernel's software checksum fallback for IPv6 extension headers, causing hardware to silently corrupt checksums. - [High] Advertising NETIF_F_HW_CSUM forces the kernel to offload checksums for non-IP protocols, which the driver's Tx path unconditionally drops. - [High] Unconditionally advertising NETIF_F_HW_CSUM forces non-TCP/UDP/SCTP packets into a buggy software fallback in the driver's Tx hot path that ignores errors, leading to silently corrupted packets. --
commit f1566dd32ecb941ad20b193c17ecae7df05ca815 Author: Michal Swiatkowski <[email protected]> ice: use NETIF_F_HW_CSUM instead of IP/IPV6 This commit replaces the IP and IPV6 checksum offload flags with HW_CSUM in the ice driver to allow hardware checksumming for IPv6 packets with extension headers. It also removes the mutual exclusivity check between TSO and GCS. > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c > b/drivers/net/ethernet/intel/ice/ice_main.c > index 5f92377d4dfc..33f252a6a22f 100644 > --- a/drivers/net/ethernet/intel/ice/ice_main.c > +++ b/drivers/net/ethernet/intel/ice/ice_main.c > @@ -3491,9 +3491,8 @@ void ice_set_netdev_features(struct net_device *netdev) > NETIF_F_RXHASH; > > csumo_features = NETIF_F_RXCSUM | > - NETIF_F_IP_CSUM | > NETIF_F_SCTP_CRC | > - NETIF_F_IPV6_CSUM; > + NETIF_F_HW_CSUM; By advertising NETIF_F_HW_CSUM, the network stack assumes the driver can handle checksums for any protocol and passes non-IP packets (e.g., from AF_PACKET injected frames) to the driver with CHECKSUM_PARTIAL. Since ice_tx_csum() strictly parses the L3 header and expects IPv4 or IPv6, returning -1 for other protocols, will this regression cause non-IP packets to be silently dropped instead of falling back to software checksums in the kernel? Additionally, skb_csum_hwoffload_help() relies on NETIF_F_IPV6_CSUM to safely fall back to software checksums when IPv6 extension headers are present. Does using NETIF_F_HW_CSUM bypass this safeguard, potentially causing legacy hardware (like E810) or E830 without GCS descriptors to compute incorrect pseudo-headers and silently corrupt IPv6 packets with extension headers? Finally, for protocols other than TCP, UDP, or SCTP, the driver falls back to calling skb_checksum_help(skb) in the default case of ice_tx_csum(). However, the driver appears to ignore the return value of skb_checksum_help(). If skb_checksum_help() fails (e.g., due to -ENOMEM during pskb_expand_head()), could this result in the packet being transmitted with an uncomputed checksum? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
