From: Christian Hopps <chopps@chopps.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Christian Hopps <chopps@chopps.org>,
devel@linux-ipsec.org,
Steffen Klassert <steffen.klassert@secunet.com>,
netdev@vger.kernel.org, Christian Hopps <chopps@labn.net>
Subject: Re: [RFC ipsec-next v2 6/8] iptfs: xfrm: Add mode_cbs module functionality
Date: Thu, 01 Feb 2024 10:34:49 -0500 [thread overview]
Message-ID: <m28r446vsn.fsf@ja.int.chopps.org> (raw)
In-Reply-To: <ZWirsc6i-8n4qSAo@hog>
[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]
Sabrina Dubroca <sd@queasysnail.net> writes:
> 2023-11-12, 22:52:17 -0500, Christian Hopps wrote:
>> From: Christian Hopps <chopps@labn.net>
>>
>> Add a set of callbacks xfrm_mode_cbs to xfrm_state. These callbacks
>> enable the addition of new xfrm modes, such as IP-TFS to be defined
>> in modules.
>
> Not a big fan of bringing back modes in modules :(
> Florian's work made the code a lot more readable.
>
>> diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
>> index 662c83beb345..4390c111410d 100644
>> --- a/net/xfrm/xfrm_output.c
>> +++ b/net/xfrm/xfrm_output.c
>> @@ -280,7 +280,9 @@ static int xfrm4_tunnel_encap_add(struct xfrm_state *x, struct sk_buff *skb)
>> skb_set_inner_network_header(skb, skb_network_offset(skb));
>> skb_set_inner_transport_header(skb, skb_transport_offset(skb));
>>
>> - skb_set_network_header(skb, -x->props.header_len);
>> + /* backup to add space for the outer encap */
>> + skb_set_network_header(skb,
>> + -x->props.header_len + x->props.enc_hdr_len);
>
> Since this only gets called for XFRM_MODE_TUNNEL, and only iptfs sets
> enc_hdr_len, do we need this change? (and same for xfrm6_tunnel_encap_add)
You're right, removed. This particular code actually predated the callbacks.
>> skb->mac_header = skb->network_header +
>> offsetof(struct iphdr, protocol);
>> skb->transport_header = skb->network_header + sizeof(*top_iph);
>> @@ -325,7 +327,8 @@ static int xfrm6_tunnel_encap_add(struct xfrm_state *x, struct sk_buff *skb)
>> skb_set_inner_network_header(skb, skb_network_offset(skb));
>> skb_set_inner_transport_header(skb, skb_transport_offset(skb));
>>
>> - skb_set_network_header(skb, -x->props.header_len);
>> + skb_set_network_header(skb,
>> + -x->props.header_len + x->props.enc_hdr_len);
>> skb->mac_header = skb->network_header +
>> offsetof(struct ipv6hdr, nexthdr);
>> skb->transport_header = skb->network_header + sizeof(*top_iph);
>> @@ -472,6 +475,8 @@ static int xfrm_outer_mode_output(struct xfrm_state *x, struct sk_buff *skb)
>> WARN_ON_ONCE(1);
>> break;
>> default:
>> + if (x->mode_cbs->prepare_output)
>
> Can x->mode_cbs be NULL here? Every other use of mode_cbs does
> if (x->mode_cbs && x->mode_cbs->FOO)
>
> (I think not at the moment since only IPTFS (and IN_TRIGGER) can reach
> this, but this inconsistency with the rest of the series struck me)
Still worth putting the guard in, fixed.
Thanks,
Chris.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
next prev parent reply other threads:[~2024-02-01 15:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 3:52 [RFC ipsec-next v2 0/8] Add IP-TFS mode to xfrm Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 1/8] iptfs: config: add CONFIG_XFRM_IPTFS Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 2/8] iptfs: uapi: ip: add ip_tfs_*_hdr packet formats Christian Hopps
2023-11-20 15:28 ` Sabrina Dubroca
2023-11-20 20:18 ` Christian Hopps
2023-11-20 22:38 ` Sabrina Dubroca
2024-02-01 14:15 ` Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 3/8] iptfs: uapi: IPPROTO_AGGFRAG AGGFRAG in ESP Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 4/8] iptfs: sysctl: allow configuration of global default values Christian Hopps
2023-11-20 23:05 ` Sabrina Dubroca
2024-02-01 13:57 ` Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 5/8] iptfs: netlink: add config (netlink) options Christian Hopps
2023-11-30 15:36 ` Sabrina Dubroca
2023-11-13 3:52 ` [RFC ipsec-next v2 6/8] iptfs: xfrm: Add mode_cbs module functionality Christian Hopps
2023-11-13 14:07 ` [devel-ipsec] " Antony Antony
2023-11-15 19:04 ` Antony Antony
2023-11-30 15:35 ` Sabrina Dubroca
2024-02-01 15:34 ` Christian Hopps [this message]
2023-11-13 3:52 ` [RFC ipsec-next v2 7/8] iptfs: xfrm: add generic iptfs defines and functionality Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 8/8] iptfs: impl: add new iptfs xfrm mode impl Christian Hopps
2023-11-13 10:05 ` kernel test robot
2023-11-30 15:33 ` Sabrina Dubroca
2024-02-02 9:44 ` Christian Hopps
2023-11-13 7:15 ` [RFC ipsec-next v2 0/8] Add IP-TFS mode to xfrm Steffen Klassert
2023-11-16 15:14 ` [devel-ipsec] " Andrew Cagney
2023-11-20 18:39 ` Christian Hopps
2023-11-20 20:00 ` [DKIM] " Antony Antony
2023-11-20 20:02 ` Antony Antony
2023-11-20 20:14 ` Christian Hopps
2023-11-21 19:13 ` Antony Antony
2023-11-16 16:02 ` Antony Antony
2024-03-07 11:05 ` Christian Hopps
2024-03-10 20:34 ` Antony Antony
2023-11-28 22:12 ` Antony Antony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m28r446vsn.fsf@ja.int.chopps.org \
--to=chopps@chopps.org \
--cc=chopps@labn.net \
--cc=devel@linux-ipsec.org \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.