From: Leon Romanovsky <leon@kernel.org>
To: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: steffen.klassert@secunet.com, herbert@gondor.apana.org.au,
antony.antony@secunet.com, davem@davemloft.net, kuba@kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next] xfrm: rework default policy structure
Date: Thu, 18 Nov 2021 21:09:15 +0200 [thread overview]
Message-ID: <YZak297hPRh3Etun@unreal> (raw)
In-Reply-To: <20211118142937.5425-1-nicolas.dichtel@6wind.com>
On Thu, Nov 18, 2021 at 03:29:37PM +0100, Nicolas Dichtel wrote:
> This is a follow up of commit f8d858e607b2 ("xfrm: make user policy API
> complete"). The goal is to align userland API to the internal structures.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
>
> This patch targets ipsec-next, but because ipsec-next has not yet been
> rebased on top of net-next, I based the patch on top of net-next.
>
> include/net/netns/xfrm.h | 6 +-----
> include/net/xfrm.h | 38 ++++++++---------------------------
> net/xfrm/xfrm_policy.c | 10 +++++++---
> net/xfrm/xfrm_user.c | 43 +++++++++++++++++-----------------------
> 4 files changed, 34 insertions(+), 63 deletions(-)
>
> diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
> index 947733a639a6..bd7c3be4af5d 100644
> --- a/include/net/netns/xfrm.h
> +++ b/include/net/netns/xfrm.h
> @@ -66,11 +66,7 @@ struct netns_xfrm {
> int sysctl_larval_drop;
> u32 sysctl_acq_expires;
>
> - u8 policy_default;
> -#define XFRM_POL_DEFAULT_IN 1
> -#define XFRM_POL_DEFAULT_OUT 2
> -#define XFRM_POL_DEFAULT_FWD 4
> -#define XFRM_POL_DEFAULT_MASK 7
> + u8 policy_default[XFRM_POLICY_MAX];
>
> #ifdef CONFIG_SYSCTL
> struct ctl_table_header *sysctl_hdr;
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index 2308210793a0..3fd1e052927e 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -1075,22 +1075,6 @@ xfrm_state_addr_cmp(const struct xfrm_tmpl *tmpl, const struct xfrm_state *x, un
> }
>
> #ifdef CONFIG_XFRM
> -static inline bool
> -xfrm_default_allow(struct net *net, int dir)
> -{
> - u8 def = net->xfrm.policy_default;
> -
> - switch (dir) {
> - case XFRM_POLICY_IN:
> - return def & XFRM_POL_DEFAULT_IN ? false : true;
> - case XFRM_POLICY_OUT:
> - return def & XFRM_POL_DEFAULT_OUT ? false : true;
> - case XFRM_POLICY_FWD:
> - return def & XFRM_POL_DEFAULT_FWD ? false : true;
> - }
> - return false;
> -}
> -
> int __xfrm_policy_check(struct sock *, int dir, struct sk_buff *skb,
> unsigned short family);
>
> @@ -1104,13 +1088,10 @@ static inline int __xfrm_policy_check2(struct sock *sk, int dir,
> if (sk && sk->sk_policy[XFRM_POLICY_IN])
> return __xfrm_policy_check(sk, ndir, skb, family);
>
> - if (xfrm_default_allow(net, dir))
> - return (!net->xfrm.policy_count[dir] && !secpath_exists(skb)) ||
> - (skb_dst(skb) && (skb_dst(skb)->flags & DST_NOPOLICY)) ||
> - __xfrm_policy_check(sk, ndir, skb, family);
> - else
> - return (skb_dst(skb) && (skb_dst(skb)->flags & DST_NOPOLICY)) ||
> - __xfrm_policy_check(sk, ndir, skb, family);
> + return (net->xfrm.policy_default[dir] == XFRM_USERPOLICY_ACCEPT &&
> + (!net->xfrm.policy_count[dir] && !secpath_exists(skb))) ||
> + (skb_dst(skb) && (skb_dst(skb)->flags & DST_NOPOLICY)) ||
> + __xfrm_policy_check(sk, ndir, skb, family);
> }
This is completely unreadable. What is the advantage of writing like this?
>
> static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family)
> @@ -1162,13 +1143,10 @@ static inline int xfrm_route_forward(struct sk_buff *skb, unsigned short family)
> {
> struct net *net = dev_net(skb->dev);
>
> - if (xfrm_default_allow(net, XFRM_POLICY_FWD))
> - return !net->xfrm.policy_count[XFRM_POLICY_OUT] ||
> - (skb_dst(skb)->flags & DST_NOXFRM) ||
> - __xfrm_route_forward(skb, family);
> - else
> - return (skb_dst(skb)->flags & DST_NOXFRM) ||
> - __xfrm_route_forward(skb, family);
> + return (net->xfrm.policy_default[XFRM_POLICY_FWD] == XFRM_USERPOLICY_ACCEPT &&
> + !net->xfrm.policy_count[XFRM_POLICY_OUT]) ||
> + (skb_dst(skb)->flags & DST_NOXFRM) ||
> + __xfrm_route_forward(skb, family);
Ditto.
Thanks
next prev parent reply other threads:[~2021-11-18 19:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-18 14:29 [PATCH net-next] xfrm: rework default policy structure Nicolas Dichtel
2021-11-18 19:09 ` Leon Romanovsky [this message]
2021-11-19 8:06 ` Nicolas Dichtel
2021-11-19 15:41 ` Leon Romanovsky
2021-11-19 17:31 ` Nicolas Dichtel
2021-11-21 14:07 ` Leon Romanovsky
2022-03-14 10:38 ` [PATCH ipsec-next v2] " Nicolas Dichtel
2022-03-15 8:32 ` Antony Antony
2022-03-18 6:27 ` Steffen Klassert
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=YZak297hPRh3Etun@unreal \
--to=leon@kernel.org \
--cc=antony.antony@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).