All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antony Antony <antony.antony@secunet.com>
To: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: <steffen.klassert@secunet.com>, <davem@davemloft.net>,
	<kuba@kernel.org>, <antony.antony@secunet.com>,
	<netdev@vger.kernel.org>
Subject: Re: [PATCH ipsec v3 0/2] xfrm: fix uapi for the default policy
Date: Wed, 15 Sep 2021 11:19:08 +0200	[thread overview]
Message-ID: <20210915091908.GA11749@moon.secunet.de> (raw)
In-Reply-To: <20210914144635.6850-1-nicolas.dichtel@6wind.com>

Hi Nicolas,

On Tue, Sep 14, 2021 at 16:46:32 +0200, Nicolas Dichtel wrote:
> This feature has just been merged after the last release, thus it's still
> time to fix the uapi.
> As stated in the thread, the uapi is based on some magic values (from the
> userland POV).

I like your proposal to make uapi 3 different variables, instead of flags.

This fix leave kernel internal representation as a flags in
struct netns_xfrm
	u8 policy_default;

I have a concern. If your patch is applied, the uapi and xfrm internal representations would be inconsistant. I think they should be the same in this case.
It would easier to follow the code path.
On the other hand we should apply this uapi change ASAP, in 5.15 release cycle, to avoid ABI change.

Could you also change xfrm policy_default to three variables?

> Here is a proposal to simplify this uapi and make it clear how to use it.
> The other problem was the notification: changing the default policy may
> radically change the packets flows.
> 
> v2 -> v3: rebase on top of ipsec tree
> 
> v1 -> v2: fix warnings reported by the kernel test robot
> 

  parent reply	other threads:[~2021-09-15  9:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210331144843.GA25749@moon.secunet.de>
2021-07-16  9:15 ` [PATCH ipsec-next] xfrm: Add possibility to set the default to block if we have no policy Antony Antony
2021-07-18  3:26   ` kernel test robot
2021-07-18  3:26     ` kernel test robot
2021-07-18  7:11 ` [PATCH v2 " Antony Antony
2021-07-22  9:43   ` Steffen Klassert
2021-08-11 16:14   ` Nicolas Dichtel
2021-08-17 11:19     ` Antony Antony
2021-08-25 10:01       ` Nicolas Dichtel
2021-09-07 19:35         ` [PATCH ipsec 0/2] xfrm: fix uapi for the default policy Nicolas Dichtel
2021-09-07 19:35           ` [PATCH ipsec 1/2] xfrm: make user policy API complete Nicolas Dichtel
2021-09-07 19:35           ` [PATCH ipsec 2/2] xfrm: notify default policy on update Nicolas Dichtel
2021-09-08  1:35             ` kernel test robot
2021-09-08  1:35               ` kernel test robot
2021-09-08  7:23               ` [PATCH ipsec v2 0/2] xfrm: fix uapi for the default policy Nicolas Dichtel
2021-09-08  7:23                 ` [PATCH ipsec v2 1/2] xfrm: make user policy API complete Nicolas Dichtel
2021-09-08  7:23                 ` [PATCH ipsec v2 2/2] xfrm: notify default policy on update Nicolas Dichtel
2021-09-08  7:23                 ` [RFC PATCH iproute2 v2] xfrm: enable to manage default policies Nicolas Dichtel
2021-09-14 14:46                 ` [PATCH ipsec v3 0/2] xfrm: fix uapi for the default policy Nicolas Dichtel
2021-09-14 14:46                   ` [PATCH ipsec v3 1/2] xfrm: make user policy API complete Nicolas Dichtel
2021-09-14 14:46                   ` [PATCH ipsec v3 2/2] xfrm: notify default policy on update Nicolas Dichtel
2021-09-14 14:46                   ` [RFC PATCH iproute2 v2] xfrm: enable to manage default policies Nicolas Dichtel
2021-09-15  9:19                   ` Antony Antony [this message]
2021-09-15  9:55                     ` [PATCH ipsec v3 0/2] xfrm: fix uapi for the default policy Nicolas Dichtel
2021-09-17  7:06                   ` Steffen Klassert
2021-09-17  7:54                     ` Nicolas Dichtel
2021-09-07 19:35           ` [RFC PATCH iproute2] xfrm: enable to manage default policies Nicolas Dichtel
2021-09-01 15:14   ` [PATCH v2 ipsec-next] xfrm: Add possibility to set the default to block if we have no policy Dmitry V. Levin
2021-09-02  9:05     ` Steffen Klassert
2021-09-19 22:40   ` Paul Cercueil
2021-09-21  6:33     ` 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=20210915091908.GA11749@moon.secunet.de \
    --to=antony.antony@secunet.com \
    --cc=davem@davemloft.net \
    --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.