mbox

[0/5] pull request (net-next): ipsec-next 2024-05-03

Message ID 20240503082732.2835810-1-steffen.klassert@secunet.com (mailing list archive)
State Accepted
Delegated to: Netdev Maintainers
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git tags/ipsec-next-2024-05-03

Message

Steffen Klassert May 3, 2024, 8:27 a.m. UTC
1) Remove Obsolete UDP_ENCAP_ESPINUDP_NON_IKE Support.
   This was defined by an early version of an IETF draft
   that did not make it to a standard.

2) Introduce direction attribute for xfrm states.
   xfrm states have a direction, a stsate can be used
   either for input or output packet processing.
   Add a direction to xfrm states to make it clear
   for what a xfrm state is used.

All patches from Antony Antony.

Please pull or let me know if there are problems.

Thanks!

The following changes since commit 267e31750ae89f845cfe7df8f577b19482d9ef9b:

  Merge branch 'phy-listing-link_topology-tracking' (2024-04-06 18:25:15 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git tags/ipsec-next-2024-05-03

for you to fetch changes up to dcf280ea0aad87e70ef1646d579d11f8a52f8b67:

  Merge remote branch 'xfrm: Introduce direction attribute for SA' (2024-05-02 10:05:11 +0200)

----------------------------------------------------------------
ipsec-next-2024-05-03

----------------------------------------------------------------
Antony Antony (5):
      udpencap: Remove Obsolete UDP_ENCAP_ESPINUDP_NON_IKE Support
      xfrm: Add Direction to the SA in or out
      xfrm: Add dir validation to "out" data path lookup
      xfrm: Add dir validation to "in" data path lookup
      xfrm: Restrict SA direction attribute to specific netlink message types

Steffen Klassert (1):
      Merge remote branch 'xfrm: Introduce direction attribute for SA'

 Documentation/networking/xfrm_proc.rst |   6 ++
 include/net/xfrm.h                     |   1 +
 include/uapi/linux/snmp.h              |   2 +
 include/uapi/linux/udp.h               |   2 +-
 include/uapi/linux/xfrm.h              |   6 ++
 net/ipv4/esp4.c                        |  12 ---
 net/ipv4/udp.c                         |   2 -
 net/ipv4/xfrm4_input.c                 |  13 ---
 net/ipv6/esp6.c                        |  12 ---
 net/ipv6/xfrm6_input.c                 |  20 ++--
 net/xfrm/xfrm_compat.c                 |   7 +-
 net/xfrm/xfrm_device.c                 |   6 ++
 net/xfrm/xfrm_input.c                  |  11 +++
 net/xfrm/xfrm_policy.c                 |   6 ++
 net/xfrm/xfrm_proc.c                   |   2 +
 net/xfrm/xfrm_replay.c                 |   3 +-
 net/xfrm/xfrm_state.c                  |   8 ++
 net/xfrm/xfrm_user.c                   | 162 +++++++++++++++++++++++++++++++--
 18 files changed, 219 insertions(+), 62 deletions(-)

Comments

Simon Horman May 4, 2024, 2:36 p.m. UTC | #1
On Fri, May 03, 2024 at 10:27:26AM +0200, Steffen Klassert wrote:
> 1) Remove Obsolete UDP_ENCAP_ESPINUDP_NON_IKE Support.
>    This was defined by an early version of an IETF draft
>    that did not make it to a standard.
> 
> 2) Introduce direction attribute for xfrm states.
>    xfrm states have a direction, a stsate can be used
>    either for input or output packet processing.
>    Add a direction to xfrm states to make it clear
>    for what a xfrm state is used.
> 
> All patches from Antony Antony.
> 
> Please pull or let me know if there are problems.

Hi Steffen, all,

This comment is not strictly related to this pull request
and certainly not intended to impede progress of it towards upstream.

However, while looking over it I noticed that Sparse flags a rather
large number of warnings in xfrm code, mostly relating to __rcu annotations.
I'm wondering if, at some point, these could be addressed somehow.
Steffen Klassert May 7, 2024, 9 a.m. UTC | #2
On Sat, May 04, 2024 at 03:36:57PM +0100, Simon Horman wrote:
> 
> Hi Steffen, all,
> 
> This comment is not strictly related to this pull request
> and certainly not intended to impede progress of it towards upstream.
> 
> However, while looking over it I noticed that Sparse flags a rather
> large number of warnings in xfrm code, mostly relating to __rcu annotations.
> I'm wondering if, at some point, these could be addressed somehow.

Yes, maybe just start to not introduce new ones and then fix
existing ones over time. I'll have a look on how I can integrate
Sparse checks in my workflow.
Simon Horman May 7, 2024, 4:54 p.m. UTC | #3
On Tue, May 07, 2024 at 11:00:27AM +0200, Steffen Klassert wrote:
> On Sat, May 04, 2024 at 03:36:57PM +0100, Simon Horman wrote:
> > 
> > Hi Steffen, all,
> > 
> > This comment is not strictly related to this pull request
> > and certainly not intended to impede progress of it towards upstream.
> > 
> > However, while looking over it I noticed that Sparse flags a rather
> > large number of warnings in xfrm code, mostly relating to __rcu annotations.
> > I'm wondering if, at some point, these could be addressed somehow.
> 
> Yes, maybe just start to not introduce new ones and then fix
> existing ones over time. I'll have a look on how I can integrate
> Sparse checks in my workflow.

Thanks Steffen,

That would be much appreciated.