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 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.