Hi Steffen,
this series addresses a few issues related to VTI. The first patch fixes
a bug in the vti6 module calling unregister_pernet_device() twice in the
error path. That's probably material for ipsec.git.
The second patch simplifies the error handling path in module init/fini
of vti6. The third patch does the same for vti. Those two are probably
material for ipsec-next.git as we're at -rc5 already. But I leave that
decision to you.
Please apply!
Mathias Krause (3):
vti6: Don't unregister pernet ops twice on init errors
vti6: Simplify error handling in module init and exit
vti: Simplify error handling in module init and exit
net/ipv4/ip_vti.c | 54 +++++++++++++++++---------------------------
net/ipv6/ip6_vti.c | 54 ++++++++++++++++----------------------------
2 files changed, 41 insertions(+), 67 deletions(-)
--
1.7.10.4
If we fail to register one of the xfrm protocol handlers we will
unregister the pernet ops twice on the error exit path. This will
probably lead to a kernel panic as the double deregistration
leads to a double kfree().
Fix this by removing one of the calls to do it only once.
Fixes: fa9ad96d49 ("vti6: Update the ipv6 side to use its own...")
Signed-off-by: Mathias Krause <redacted>
---
net/ipv6/ip6_vti.c | 3 ---
1 file changed, 3 deletions(-)
The error handling in the module init and exit functions can be
shortened to safe us some code.
1/ Remove the code duplications in the init function, jump straight to
the existing cleanup code by adding some labels. Also give the error
message some more value by telling the reason why loading the module has
failed.
2/ Remove the error handling in the exit function as the only legitimate
reason xfrm6_protocol_deregister() might fail is inet6_del_protocol()
returning -1. That, in turn, means some other protocol handler had been
registered for this very protocol in the meantime. But that essentially
means we haven't been handling that protocol any more, anyway. What it
definitely means not is that we "can't deregister protocol". Therefore
just get rid of that bogus warning. It's plain wrong.
Signed-off-by: Mathias Krause <redacted>
---
net/ipv6/ip6_vti.c | 51 +++++++++++++++++---------------------------
1 file changed, 20 insertions(+), 31 deletions(-)
The error handling in the module init and exit functions can be
shortened to safe us some code.
1/ Remove the code duplications in the init function, jump straight to
the existing cleanup code by adding some labels. Also give the error
message some more value by telling the reason why loading the module has
failed. Furthermore fix the "IPSec" typo -- it should be "IPsec" instead.
2/ Remove the error handling in the exit function as the only legitimate
reason xfrm4_protocol_deregister() might fail is inet_del_protocol()
returning -1. That, in turn, means some other protocol handler had been
registered for this very protocol in the meantime. But that essentially
means we haven't been handling that protocol any more, anyway. What it
definitely means not is that we "can't deregister tunnel". Therefore
just get rid of that bogus warning. It's plain wrong.
Signed-off-by: Mathias Krause <redacted>
---
net/ipv4/ip_vti.c | 54 ++++++++++++++++++---------------------------
1 file changed, 21 insertions(+), 33 deletions(-)
On Fri, May 09, 2014 at 11:43:40PM +0200, Mathias Krause wrote:
If we fail to register one of the xfrm protocol handlers we will
unregister the pernet ops twice on the error exit path. This will
probably lead to a kernel panic as the double deregistration
leads to a double kfree().
Fix this by removing one of the calls to do it only once.
Fixes: fa9ad96d49 ("vti6: Update the ipv6 side to use its own...")
Signed-off-by: Mathias Krause <redacted>
On Fri, May 09, 2014 at 11:43:39PM +0200, Mathias Krause wrote:
Hi Steffen,
this series addresses a few issues related to VTI. The first patch fixes
a bug in the vti6 module calling unregister_pernet_device() twice in the
error path. That's probably material for ipsec.git.
The second patch simplifies the error handling path in module init/fini
of vti6. The third patch does the same for vti. Those two are probably
material for ipsec-next.git as we're at -rc5 already. But I leave that
decision to you.
Right, patches two and three should go to ipsec-next. But the second
patch does not apply without the first patch. Please send separate
patchsets for ipsec and ipsec-next in future.
Thanks!
On 13 May 2014 10:41, Steffen Klassert [off-list ref] wrote:
On Fri, May 09, 2014 at 11:43:39PM +0200, Mathias Krause wrote:
quoted
Hi Steffen,
this series addresses a few issues related to VTI. The first patch fixes
a bug in the vti6 module calling unregister_pernet_device() twice in the
error path. That's probably material for ipsec.git.
The second patch simplifies the error handling path in module init/fini
of vti6. The third patch does the same for vti. Those two are probably
material for ipsec-next.git as we're at -rc5 already. But I leave that
decision to you.
Right, patches two and three should go to ipsec-next. But the second
patch does not apply without the first patch. Please send separate
patchsets for ipsec and ipsec-next in future.
Patch 2 depends on patch 1 because it's a series ;) I explicitly
didn't want to create different patches for ipsec-next because I
wanted to avoid the merge conflicts on your side when ipsec-next would
rebase to/merge a tree which would contain patch 1.
One way to solve it would be to merge ipsec/master into
ipsec-next/master prior to applying patches 2 and 3 -- just as Dave
does with net-next from time to time, i.e. merging net/master. Another
way would be to wait until Dave has merged ipsec/master into
net/master and after that, has merged net/master into net-next. This
way you can merge net-next into ipsec-next and after that apply
patches 2 and 3 without conflicts. Your choice. You know the
interdependencies between these trees better than me. But the first
solution sounds simpler to me. ;)
Mathias
On Tue, May 13, 2014 at 10:38:32PM +0200, Mathias Krause wrote:
On 13 May 2014 10:41, Steffen Klassert [off-list ref] wrote:
quoted
On Fri, May 09, 2014 at 11:43:39PM +0200, Mathias Krause wrote:
quoted
Hi Steffen,
this series addresses a few issues related to VTI. The first patch fixes
a bug in the vti6 module calling unregister_pernet_device() twice in the
error path. That's probably material for ipsec.git.
The second patch simplifies the error handling path in module init/fini
of vti6. The third patch does the same for vti. Those two are probably
material for ipsec-next.git as we're at -rc5 already. But I leave that
decision to you.
Right, patches two and three should go to ipsec-next. But the second
patch does not apply without the first patch. Please send separate
patchsets for ipsec and ipsec-next in future.
Patch 2 depends on patch 1 because it's a series ;) I explicitly
didn't want to create different patches for ipsec-next because I
wanted to avoid the merge conflicts on your side when ipsec-next would
rebase to/merge a tree which would contain patch 1.
One way to solve it would be to merge ipsec/master into
ipsec-next/master prior to applying patches 2 and 3 -- just as Dave
does with net-next from time to time, i.e. merging net/master. Another
way would be to wait until Dave has merged ipsec/master into
net/master and after that, has merged net/master into net-next. This
way you can merge net-next into ipsec-next and after that apply
patches 2 and 3 without conflicts. Your choice. You know the
interdependencies between these trees better than me. But the first
solution sounds simpler to me. ;)
I've applied the remaining two patches to ipsec-next now, thanks!