Hi Steffen,
Today's linux-next merge of the ipsec-next tree got a conflict in
include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
from function prototypes") from the net-next tree and commit aba826958830
("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
callback") from the ipsec-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell [email protected]
diff --cc include/net/xfrm.h
index 7657461,c7afa6e..0000000
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@@ -1493,39 -1495,35 +1499,39 @@@ static inline int xfrm4_rcv_spi(struct
return xfrm4_rcv_encap(skb, nexthdr, spi, 0);
}
-extern int xfrm4_extract_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm4_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
-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_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);
-extern int xfrm6_transport_finish(struct sk_buff *skb, int async);
-extern int xfrm6_rcv(struct sk_buff *skb);
-extern int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
- xfrm_address_t *saddr, u8 proto);
-extern int xfrm6_tunnel_register(struct xfrm6_tunnel *handler, unsigned short family);
-extern int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler, unsigned short family);
-extern __be32 xfrm6_tunnel_alloc_spi(struct net *net, xfrm_address_t *saddr);
-extern __be32 xfrm6_tunnel_spi_lookup(struct net *net, const xfrm_address_t *saddr);
-extern int xfrm6_extract_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm6_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm6_output(struct sk_buff *skb);
-extern int xfrm6_output_finish(struct sk_buff *skb);
-extern int xfrm6_find_1stfragopt(struct xfrm_state *x, struct sk_buff *skb,
- u8 **prevhdr);
+int xfrm4_extract_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm4_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm4_output(struct sk_buff *skb);
+int xfrm4_output_finish(struct sk_buff *skb);
+int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family);
+int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short family);
- int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel *handler);
- int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel *handler);
++int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel_notifier *handler);
++int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel_notifier *handler);
+void xfrm4_local_error(struct sk_buff *skb, u32 mtu);
+int xfrm6_extract_header(struct sk_buff *skb);
+int xfrm6_extract_input(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm6_rcv_spi(struct sk_buff *skb, int nexthdr, __be32 spi);
+int xfrm6_transport_finish(struct sk_buff *skb, int async);
+int xfrm6_rcv(struct sk_buff *skb);
+int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
+ xfrm_address_t *saddr, u8 proto);
+int xfrm6_tunnel_register(struct xfrm6_tunnel *handler, unsigned short family);
+int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler,
+ unsigned short family);
+__be32 xfrm6_tunnel_alloc_spi(struct net *net, xfrm_address_t *saddr);
+__be32 xfrm6_tunnel_spi_lookup(struct net *net, const xfrm_address_t *saddr);
+int xfrm6_extract_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm6_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm6_output(struct sk_buff *skb);
+int xfrm6_output_finish(struct sk_buff *skb);
+int xfrm6_find_1stfragopt(struct xfrm_state *x, struct sk_buff *skb,
+ u8 **prevhdr);
+void xfrm6_local_error(struct sk_buff *skb, u32 mtu);
#ifdef CONFIG_XFRM
-extern int xfrm4_udp_encap_rcv(struct sock *sk, struct sk_buff *skb);
-extern int xfrm_user_policy(struct sock *sk, int optname, u8 __user *optval, int optlen);
+int xfrm4_udp_encap_rcv(struct sock *sk, struct sk_buff *skb);
+int xfrm_user_policy(struct sock *sk, int optname,
+ u8 __user *optval, int optlen);
#else
static inline int xfrm_user_policy(struct sock *sk, int optname, u8 __user *optval, int optlen)
{
Hi Stephen.
On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> Hi Steffen,
>
> Today's linux-next merge of the ipsec-next tree got a conflict in
> include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> from function prototypes") from the net-next tree and commit aba826958830
> ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> callback") from the ipsec-next tree.
>
Thanks for the information, I'll do a rebase of the ipsec-next
tree tomorrow.
Hi Steffen,
On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert <[email protected]> wrote:
>
> On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the ipsec-next tree got a conflict in
> > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > from function prototypes") from the net-next tree and commit aba826958830
> > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > callback") from the ipsec-next tree.
>
> Thanks for the information, I'll do a rebase of the ipsec-next
> tree tomorrow.
Did you miss the end of the next paragraph: "no action is required"?
Dave can fix this up (like I did) when he merges your tree into his.
--
Cheers,
Stephen Rothwell [email protected]
On Wed, Sep 25, 2013 at 09:59:19AM +1000, Stephen Rothwell wrote:
> Hi Steffen,
>
> On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert <[email protected]> wrote:
> >
> > On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the ipsec-next tree got a conflict in
> > > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > > from function prototypes") from the net-next tree and commit aba826958830
> > > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > > callback") from the ipsec-next tree.
> >
> > Thanks for the information, I'll do a rebase of the ipsec-next
> > tree tomorrow.
>
> Did you miss the end of the next paragraph: "no action is required"?
> Dave can fix this up (like I did) when he merges your tree into his.
>
I applied this patch shortly before the merge window opened, it is a left
over from the last develpoment cycle. I already rebased my tree onto
net-next in the past if that happened, even if there were no merge
conflicts. I did that just to see if everything still works. But I
could also do a test merge to see if everything still works and ask
to pull without a rebase then if this is the prefered way. Would make
my life easier :)
Hi Steffen,
On Wed, 25 Sep 2013 07:29:23 +0200 Steffen Klassert <[email protected]> wrote:
>
> On Wed, Sep 25, 2013 at 09:59:19AM +1000, Stephen Rothwell wrote:
> >
> > On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert <[email protected]> wrote:
> > >
> > > On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> > > >
> > > > Today's linux-next merge of the ipsec-next tree got a conflict in
> > > > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > > > from function prototypes") from the net-next tree and commit aba826958830
> > > > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > > > callback") from the ipsec-next tree.
> > >
> > > Thanks for the information, I'll do a rebase of the ipsec-next
> > > tree tomorrow.
> >
> > Did you miss the end of the next paragraph: "no action is required"?
> > Dave can fix this up (like I did) when he merges your tree into his.
>
> I applied this patch shortly before the merge window opened, it is a left
> over from the last develpoment cycle. I already rebased my tree onto
> net-next in the past if that happened, even if there were no merge
> conflicts. I did that just to see if everything still works. But I
> could also do a test merge to see if everything still works and ask
> to pull without a rebase then if this is the prefered way. Would make
> my life easier :)
That would be up to Dave ...
--
Cheers,
Stephen Rothwell [email protected]