Re: [PATCH v6 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation
"Hudson, Nick" <[email protected]> Tue, 19 May 2026 10:45:46 +0000
| Newsgroups | dev.linux.lists.sashiko,org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_BDE7C93C-EE7F-44A6-8F60-3CE067AED8B5 Content-Type: multipart/alternative; boundary="Apple-Mail=_F196DE3E-781D-4C80-BA94-BBEF43B7D978" --Apple-Mail=_F196DE3E-781D-4C80-BA94-BBEF43B7D978 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 5, 2026, at 5:14=E2=80=AFAM, [email protected] wrote: >=20 > !-------------------------------------------------------------------| > This Message Is =46rom an External Sender > This message came from outside your organization. > |-------------------------------------------------------------------! >=20 > Thank you for your contribution! Sashiko AI review found 1 potential = issue(s) to consider: > - [High] The documented API behavior fails to clear tunnel modifier = GSO flags, leading to SKB GSO state corruption. > -- >=20 > commit b28df908f04d4d037671bd0f85e9d43e6c3ddef9 > Author: Nick Hudson <[email protected]> >=20 > bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation >=20 > This commit adds new bpf_skb_adjust_room() decapsulation flags to = describe > which tunnel layer is being removed. This allows later changes to = update > tunnel-related GSO state accordingly during decapsulation. >=20 >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h > [ ... ] >> + * * **BPF_F_ADJ_ROOM_DECAP_L4_UDP**: >> + * Clear UDP tunnel GSO flags (SKB_GSO_UDP_TUNNEL and >> + * SKB_GSO_UDP_TUNNEL_CSUM) when decapsulating a UDP = tunnel. >=20 > If a tunnel packet has remote checksum offload, does this = documentation > imply that tunnel modifier flags like SKB_GSO_TUNNEL_REMCSUM and > SKB_GSO_PARTIAL are left intact when the base UDP flags are cleared? >=20 > [ ... ] >> + * When using the decapsulation flags above, the = skb->encapsulation >> + * flag is automatically cleared if all tunnel-specific GSO = flags >> + * (SKB_GSO_UDP_TUNNEL, SKB_GSO_UDP_TUNNEL_CSUM, = SKB_GSO_GRE, >> + * SKB_GSO_GRE_CSUM, SKB_GSO_IPXIP4, SKB_GSO_IPXIP6) have = been >> + * removed from the packet. This handles cases where all = tunnel >> + * layers have been decapsulated. >=20 > If the base tunnel flags are cleared but tunnel modifier flags like > SKB_GSO_TUNNEL_REMCSUM remain, will the packet be left in an invalid > state where skb->encapsulation is 0 but tunnel offload features are > still present? This might cause the network stack's segmentation code = to > process a packet with tunnel offload features but no actual tunnel. >=20 REMCSUM was remove as per maintainers advice: " REMCSUM previously not included in the series. It is a non-obvious and rare enough feature that I would exclude it, or move it to a separate patch. =E2=80=9C = https://lore.kernel.org/bpf/[email protected]/= > Also, SKB_GSO_ESP appears to be missing from the list of = tunnel-specific > GSO flags that prevent clearing skb->encapsulation. Could this result = in > skb->encapsulation being cleared prematurely if an ESP tunnel is still > present? >=20 The code in v6 5/6 handles SKB_GSO_ESP correctly. > --=20 > Sashiko AI review =C2=B7 = https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260504101759.= [email protected]?part=3D3__;Iw!!GjvTz_vk!XtvRB5f4u7U30_eGAxcoo= z-ntTaRbpqZLQdXKnJxBlHKlpwg28UOtr33DUpjhYdnKIgstpZu2LU_fwJYC6ak$ --Apple-Mail=_F196DE3E-781D-4C80-BA94-BBEF43B7D978 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On May 5, 2026, at 5:14=E2=80=AFAM, = [email protected] wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>!---------------------------= ----------------------------------------|<br> This Message Is =46rom= an External Sender<br> This message came from outside your = organization.<br>|--------------------------------------------------------= -----------!<br><br>Thank you for your contribution! Sashiko AI review = found 1 potential issue(s) to consider:<br>- [High] The documented API = behavior fails to clear tunnel modifier GSO flags, leading to SKB GSO = state corruption.<br>--<br><br>commit = b28df908f04d4d037671bd0f85e9d43e6c3ddef9<br>Author: Nick Hudson = <[email protected]><br><br>bpf: add BPF_F_ADJ_ROOM_DECAP_* flags = for tunnel decapsulation<br><br>This commit adds new = bpf_skb_adjust_room() decapsulation flags to describe<br>which tunnel = layer is being removed. This allows later changes to = update<br>tunnel-related GSO state accordingly during = decapsulation.<br><br><blockquote type=3D"cite">diff --git = a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h<br>--- = a/include/uapi/linux/bpf.h<br>+++ = b/include/uapi/linux/bpf.h<br></blockquote>[ ... ]<br><blockquote = type=3D"cite">+ *<span class=3D"Apple-tab-span" style=3D"white-space:pre">= </span><span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>* **BPF_F_ADJ_ROOM_DECAP_L4_UDP**:<br>+ *<span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span> = Clear UDP tunnel GSO flags (SKB_GSO_UDP_TUNNEL and<br>+ *<span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span> = SKB_GSO_UDP_TUNNEL_CSUM) when decapsulating a UDP = tunnel.<br></blockquote><br>If a tunnel packet has remote checksum = offload, does this documentation<br>imply that tunnel modifier flags = like SKB_GSO_TUNNEL_REMCSUM and<br>SKB_GSO_PARTIAL are left intact when = the base UDP flags are cleared?<br><br>[ ... ]<br><blockquote = type=3D"cite">+ *<span class=3D"Apple-tab-span" style=3D"white-space:pre">= </span><span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>When using the decapsulation flags above, the = skb->encapsulation<br>+ *<span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>flag is automatically cleared if = all tunnel-specific GSO flags<br>+ *<span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>(SKB_GSO_UDP_TUNNEL, = SKB_GSO_UDP_TUNNEL_CSUM, SKB_GSO_GRE,<br>+ *<span class=3D"Apple-tab-span"= style=3D"white-space:pre"> </span><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>SKB_GSO_GRE_CSUM, SKB_GSO_IPXIP4, = SKB_GSO_IPXIP6) have been<br>+ *<span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>removed from the packet. This = handles cases where all tunnel<br>+ *<span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>layers have been = decapsulated.<br></blockquote><br>If the base tunnel flags are cleared = but tunnel modifier flags like<br>SKB_GSO_TUNNEL_REMCSUM remain, will = the packet be left in an invalid<br>state where skb->encapsulation is = 0 but tunnel offload features are<br>still present? This might cause the = network stack's segmentation code to<br>process a packet with tunnel = offload features but no actual = tunnel.<br><br></div></div></blockquote><div><br></div><div>REMCSUM was = remove as per maintainers = advice:</div><div><br></div><div>"</div><div>REMCSUM previously = not included in the series.<br><br>It is a non-obvious and rare enough = feature that I would exclude it,<br>or move it to a separate = patch.</div><div>=E2=80=9C</div><div><br></div><div><a = href=3D"https://lore.kernel.org/bpf/willemdebruijn.kernel.245c592e6d270@gm= ail.com/">https://lore.kernel.org/bpf/willemdebruijn.kernel.245c592e6d270@= gmail.com/</a><br></div><div><br></div><br><blockquote = type=3D"cite"><div><div>Also, SKB_GSO_ESP appears to be missing from the = list of tunnel-specific<br>GSO flags that prevent clearing = skb->encapsulation. Could this result in<br>skb->encapsulation = being cleared prematurely if an ESP tunnel is = still<br>present?<br><br></div></div></blockquote><div><br></div><div>The = code in v6 5/6 handles SKB_GSO_ESP = correctly.</div><div><br></div><br><blockquote = type=3D"cite"><div><div>-- <br>Sashiko AI review =C2=B7 = https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260504101759.= [email protected]?part=3D3__;Iw!!GjvTz_vk!XtvRB5f4u7U30_eGAxcoo= z-ntTaRbpqZLQdXKnJxBlHKlpwg28UOtr33DUpjhYdnKIgstpZu2LU_fwJYC6ak$ = <br></div></div></blockquote></div><br></body></html>= --Apple-Mail=_F196DE3E-781D-4C80-BA94-BBEF43B7D978-- --Apple-Mail=_BDE7C93C-EE7F-44A6-8F60-3CE067AED8B5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCc8w ggShMIIESKADAgECAhMxAAAAIa0XYPGypwcKAAAAAAAhMAoGCCqGSM49BAMCMD8xITAfBgNVBAoT GEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLjEaMBgGA1UEAxMRQWthbWFpQ29ycFJvb3QtRzEwHhcN MjQxMTIxMTgzNzUyWhcNMzQxMTIxMTg0NzUyWjA8MSEwHwYDVQQKExhBa2FtYWkgVGVjaG5vbG9n aWVzIEluYy4xFzAVBgNVBAMTDkFrYW1haUNsaWVudENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD QgAEjkdeMHsSTytADJ7eJ+O+5mpBfm9hVC6Cg9Wf+ER8HXid3E68IHjcCTNFSiezqYclAnIalS1I cl6hRFZiacQkd6OCAyQwggMgMBIGCSsGAQQBgjcVAQQFAgMBAAEwIwYJKwYBBAGCNxUCBBYEFOa0 4dX2BYnqjkbEVEwLgf7BQJ7ZMB0GA1UdDgQWBBS2N+ieDVUAjPmykf1ahsljEXmtXDCBrwYDVR0g BIGnMIGkMIGhBgsqAwSPTgEJCQgBATCBkTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4A dDA1BggrBgEFBQcCARYpaHR0cDovL2FrYW1haWNybC5ha2FtYWkuY29tL0FrYW1haUNQUy5wZGYw bAYDVR0lBGUwYwYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICBgorBgEEAYI3CgMEBgor BgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAwkGCSsGAQQBgjcVBQYKKwYBBAGCNxQCATAZBgkr BgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNV HSMEGDAWgBStAYfq3FmusRM5lU0PV6Akhot7vTCBgAYDVR0fBHkwdzB1oHOgcYYxaHR0cDovL2Fr YW1haWNybC5ha2FtYWkuY29tL0FrYW1haUNvcnBSb290LUcxLmNybIY8aHR0cDovL2FrYW1haWNy bC5kZncwMS5jb3JwLmFrYW1haS5jb20vQWthbWFpQ29ycFJvb3QtRzEuY3JsMIHIBggrBgEFBQcB AQSBuzCBuDA9BggrBgEFBQcwAoYxaHR0cDovL2FrYW1haWNybC5ha2FtYWkuY29tL0FrYW1haUNv cnBSb290LUcxLmNydDBIBggrBgEFBQcwAoY8aHR0cDovL2FrYW1haWNybC5kZncwMS5jb3JwLmFr YW1haS5jb20vQWthbWFpQ29ycFJvb3QtRzEuY3J0MC0GCCsGAQUFBzABhiFodHRwOi8vYWthbWFp b2NzcC5ha2FtYWkuY29tL29jc3AwCgYIKoZIzj0EAwIDRwAwRAIgaUoJ7eBk/qNcBVTJW5NC4NsO 6j4/6zQoKeKgOpeiXQUCIGkbSN83n1mMURZIK92KFRtn2X1nrZ7rcNuAQD5bvH1bMIIFJjCCBMyg AwIBAgITFwALeewU5YRKbvcMWwABAAt57DAKBggqhkjOPQQDAjA8MSEwHwYDVQQKExhBa2FtYWkg VGVjaG5vbG9naWVzIEluYy4xFzAVBgNVBAMTDkFrYW1haUNsaWVudENBMB4XDTI2MDMyMDEzNDgw MloXDTI4MDMxOTEzNDgwMlowUDEZMBcGA1UECxMQTWFjQm9vayBQcm8tM1FIVDEQMA4GA1UEAxMH bmh1ZHNvbjEhMB8GCSqGSIb3DQEJARYSbmh1ZHNvbkBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAx+gvYqVaQAmc/yNlMv3t5CK6FN7++3ZChJpOElnFyZWj3h+VwSqN 5WD4VQn5DL515KovgCiv63DeQ1NuXNu3XKKeakHyssixhIL2hqjlPFnsrwXJ2R9B9hAGIiOBy2rK Var+w87AFUZ70jsZlI70IBnJOYsPYnZRmXBytTxVWk9V7Nnh10RuUfkZE2Ry+P18Z7glHYoQeksi hz/9uqRUEqt23qDYBR1J7bB+SSW5A3LmoTEugWYzayxb9iM0vVleEHqeuN5nihGn8Y7nIrs5sIo8 6AG2Bjl0O2VgWWVfqhl9IMQlx1ZxHAicuMvDN49LD1yMkqx+LeBLboiFQQ0MVQIDAQABo4ICzDCC AsgwCwYDVR0PBAQDAgeAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAdBgNVHQ4EFgQUD8PIZa7GFc+oX4RLtUq8oUrOL/IwRgYDVR0RBD8wPaAnBgorBgEEAYI3FAID oBkMF25odWRzb25AY29ycC5ha2FtYWkuY29tgRJuaHVkc29uQGFrYW1haS5jb20wHwYDVR0jBBgw FoAUtjfong1VAIz5spH9WobJYxF5rVwwgYAGA1UdHwR5MHcwdaBzoHGGMWh0dHA6Ly9ha2FtYWlj cmwuYWthbWFpLmNvbS9Ba2FtYWlDbGllbnRDQSgxKS5jcmyGPGh0dHA6Ly9ha2FtYWljcmwuZGZ3 MDEuY29ycC5ha2FtYWkuY29tL0FrYW1haUNsaWVudENBKDEpLmNybDCByAYIKwYBBQUHAQEEgbsw gbgwPQYIKwYBBQUHMAKGMWh0dHA6Ly9ha2FtYWljcmwuYWthbWFpLmNvbS9Ba2FtYWlDbGllbnRD QSgxKS5jcnQwSAYIKwYBBQUHMAKGPGh0dHA6Ly9ha2FtYWljcmwuZGZ3MDEuY29ycC5ha2FtYWku Y29tL0FrYW1haUNsaWVudENBKDEpLmNydDAtBggrBgEFBQcwAYYhaHR0cDovL2FrYW1haW9jc3Au YWthbWFpLmNvbS9vY3NwMDsGCSsGAQQBgjcVBwQuMCwGJCsGAQQBgjcVCILO5TqHuNQtgYWLB6Lj IYbSD4FJhaXDEJrVfwIBZAIBUzA1BgkrBgEEAYI3FQoEKDAmMAoGCCsGAQUFBwMCMAoGCCsGAQUF BwMEMAwGCisGAQQBgjcKAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMAoGCCqGSM49BAMCA0gAMEUCIBZ79THtRc/r DXpg8rSeL4tPy9/eLjXnJvYW5Ek2SUJ8AiEA5j0Wa0K9P2Vumn7N4F5MpbHW2t/kxsdwUu2Vzp6S 5BUxggHpMIIB5QIBATBTMDwxITAfBgNVBAoTGEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLjEXMBUG A1UEAxMOQWthbWFpQ2xpZW50Q0ECExcAC3nsFOWESm73DFsAAQALeewwDQYJYIZIAWUDBAIBBQCg aTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yNjA1MTkxMDQ1MzZa MC8GCSqGSIb3DQEJBDEiBCCPpE0pjJxwwLLN3vK5UckPYToD/pWSW72aQ8Dv24oH+TANBgkqhkiG 9w0BAQsFAASCAQCZlsqdyJPtZrA4HnICBy2ZAqv8CPlXwvSXDM419OtFb66ZHp+ohCid9DUGyA3B bSsQUdlc9L2Q5YWRD0vQeFjDnTY4U9K7w8QyDuGWHV/d2P7ZNG+X2DeIUXtEEJbhbkFVhSx22r4x 7CoM8vKU1VQ/OKkiDMnLz5YDFCPLPFZxT1zRoXGj4RwaNwTm2sGI0up60RMeTFttpeaxzjK6+dqn jaWUlVDUeJ5Iarkpcs5kGZiYSbeyishuhiku78HTtxZkyeJdl+8jbh+CX+jjPjvTdULVFJlyEpsm zYqYNjnvWeJesOq4Bcbi/GgOxbsc9E2f6itb0dzFs6062dVnJw7CAAAAAAAA --Apple-Mail=_BDE7C93C-EE7F-44A6-8F60-3CE067AED8B5--