From: Steffen Klassert <steffen.klassert@secunet.com>
To: Emmanuel Thierry <emmanuel.thierry@telecom-bretagne.eu>
Cc: jamal <j.hadi123@gmail.com>, Romain KUNTZ <r.kuntz@ipflavors.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
herbert@gondor.hengli.com.au,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jamal Hadi Salim <hadi@cyberus.ca>
Subject: Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.
Date: Thu, 7 Feb 2013 13:54:37 +0100 [thread overview]
Message-ID: <20130207125437.GC17794@secunet.com> (raw)
In-Reply-To: <2BEAF521-7218-415B-98ED-EC0812903479@telecom-bretagne.eu>
On Thu, Feb 07, 2013 at 12:08:22PM +0100, Emmanuel Thierry wrote:
>
> This is a nice idea, however you keep the insertion asymmetric. The usage of xfrm marks in non-conflicting cases will be made possible, but it stays disturbing for a user as the initial example will still have the same behavior:
> * Inserting the marked one then the unmarked will succeed
> * Inserting the unmarked then the marked one will fail
> This gives to the user the feeling of an indeterministic behavior of the xfrm module.
This was intended. Inserting the marked one then the unmarked
is a working scenario. Some users might rely on it, so we can't
change this as you proposed.
On the other hand, inserting the unmarked one then the marked
might result in a wrong policy lookup, so we can't allow this.
The only possibility we have, is inserting with different
priorites and that's what I'm proposing.
I fear we have to live with that asymmetric behaviour if
both policies have the same priority.
WARNING: multiple messages have this Message-ID (diff)
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Emmanuel Thierry <emmanuel.thierry@telecom-bretagne.eu>
Cc: jamal <j.hadi123@gmail.com>, Romain KUNTZ <r.kuntz@ipflavors.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
herbert@gondor.apana.org.au,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jamal Hadi Salim <hadi@cyberus.ca>
Subject: Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.
Date: Thu, 7 Feb 2013 13:54:37 +0100 [thread overview]
Message-ID: <20130207125437.GC17794@secunet.com> (raw)
In-Reply-To: <2BEAF521-7218-415B-98ED-EC0812903479@telecom-bretagne.eu>
On Thu, Feb 07, 2013 at 12:08:22PM +0100, Emmanuel Thierry wrote:
>
> This is a nice idea, however you keep the insertion asymmetric. The usage of xfrm marks in non-conflicting cases will be made possible, but it stays disturbing for a user as the initial example will still have the same behavior:
> * Inserting the marked one then the unmarked will succeed
> * Inserting the unmarked then the marked one will fail
> This gives to the user the feeling of an indeterministic behavior of the xfrm module.
This was intended. Inserting the marked one then the unmarked
is a working scenario. Some users might rely on it, so we can't
change this as you proposed.
On the other hand, inserting the unmarked one then the marked
might result in a wrong policy lookup, so we can't allow this.
The only possibility we have, is inserting with different
priorites and that's what I'm proposing.
I fear we have to live with that asymmetric behaviour if
both policies have the same priority.
next prev parent reply other threads:[~2013-02-07 12:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-02 17:27 [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask Romain KUNTZ
2013-02-02 17:27 ` Romain KUNTZ
2013-02-05 8:12 ` Steffen Klassert
2013-02-05 8:12 ` Steffen Klassert
2013-02-06 13:14 ` jamal
2013-02-06 13:14 ` jamal
2013-02-06 13:53 ` Emmanuel Thierry
2013-02-06 13:53 ` Emmanuel Thierry
2013-02-06 14:30 ` Jamal Hadi Salim
2013-02-06 14:30 ` Jamal Hadi Salim
2013-02-06 14:39 ` Emmanuel Thierry
2013-02-06 14:39 ` Emmanuel Thierry
2013-02-06 15:50 ` Jamal Hadi Salim
2013-02-06 15:50 ` Jamal Hadi Salim
2013-02-07 10:49 ` Steffen Klassert
2013-02-07 10:49 ` Steffen Klassert
2013-02-07 11:08 ` Emmanuel Thierry
2013-02-07 11:08 ` Emmanuel Thierry
2013-02-07 11:16 ` Emmanuel Thierry
2013-02-07 11:16 ` Emmanuel Thierry
2013-02-07 12:54 ` Steffen Klassert [this message]
2013-02-07 12:54 ` Steffen Klassert
2013-02-08 14:16 ` Emmanuel Thierry
2013-02-08 14:16 ` Emmanuel Thierry
2013-02-11 12:57 ` Romain KUNTZ
2013-02-11 12:57 ` Romain KUNTZ
2013-02-11 13:04 ` Steffen Klassert
2013-02-11 13:04 ` 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=20130207125437.GC17794@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=emmanuel.thierry@telecom-bretagne.eu \
--cc=hadi@cyberus.ca \
--cc=herbert@gondor.hengli.com.au \
--cc=j.hadi123@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=r.kuntz@ipflavors.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.