diff options
author | Fan Du <fan.du@windriver.com> | 2013-08-28 15:09:40 +0800 |
---|---|---|
committer | Steffen Klassert <steffen.klassert@secunet.com> | 2013-08-28 09:22:17 +0200 |
commit | aba8269588301f7778bea811d6f7ec74c2e37279 (patch) | |
tree | caa13792e548e860403cf513a6f6d80f0838602a /include/net/xfrm.h | |
parent | 0806ae4cc8722b2d2822fe3fa3f516f2da6b9459 (diff) |
{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback
Some thoughts on IPv4 VTI implementation:
The connection between VTI receiving part and xfrm tunnel mode input process
is hardly a "xfrm_tunnel", xfrm_tunnel is used in places where, e.g ipip/sit
and xfrm4_tunnel, acts like a true "tunnel" device.
In addition, IMHO, VTI doesn't need vti_err to do something meaningful, as all
VTI needs is just a notifier to be called whenever xfrm_input ingress a packet
to update statistics.
A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
to check packet authentication or encryption rightness. PMTU update is taken
care of in this stage by protocol error handler.
Then the packet is rearranged properly depending on whether it's transport
mode or tunnel mode packed by mode "input" handler. The VTI handler code
takes effects in this stage in tunnel mode only. So it neither need propagate
PMTU, as it has already been done if necessary, nor the VTI handler is
qualified as a xfrm_tunnel.
So this patch introduces xfrm_tunnel_notifier and meanwhile wipe out vti_err
code.
Signed-off-by: Fan Du <fan.du@windriver.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: David S. Miller <davem@davemloft.net>
Reviewed-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Diffstat (limited to 'include/net/xfrm.h')
-rw-r--r-- | include/net/xfrm.h | 10 |
1 files changed, 8 insertions, 2 deletions
diff --git a/include/net/xfrm.h b/include/net/xfrm.h index 89d3d8ae204e..c7afa6e476c8 100644 --- a/include/net/xfrm.h +++ b/include/net/xfrm.h @@ -1352,6 +1352,12 @@ struct xfrm_tunnel { int priority; }; +struct xfrm_tunnel_notifier { + int (*handler)(struct sk_buff *skb); + struct xfrm_tunnel_notifier __rcu *next; + int priority; +}; + struct xfrm6_tunnel { int (*handler)(struct sk_buff *skb); int (*err_handler)(struct sk_buff *skb, struct inet6_skb_parm *opt, @@ -1495,8 +1501,8 @@ extern int xfrm4_output(struct sk_buff *skb); extern int xfrm4_output_finish(struct sk_buff *skb); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family); extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short family); -extern int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel *handler); -extern int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel *handler); +extern int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel_notifier *handler); +extern int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel_notifier *handler); extern int xfrm6_extract_header(struct sk_buff *skb); extern int xfrm6_extract_input(struct xfrm_state *x, struct sk_buff *skb); extern int xfrm6_rcv_spi(struct sk_buff *skb, int nexthdr, __be32 spi); |