[107/107] IPVS netns exit causes crash in conntrack

From: Greg KH
Date: Fri Jul 08 2011 - 01:06:37 EST


2.6.39-stable review patch. If anyone has any objections, please let us know.

------------------

From: Hans Schillstrom <hans.schillstrom@xxxxxxxxxxxx>

commit 8f4e0a18682d91abfad72ede3d3cb5f3ebdf54b4 upstream.

Quote from Patric Mc Hardy
"This looks like nfnetlink.c excited and destroyed the nfnl socket, but
ip_vs was still holding a reference to a conntrack. When the conntrack
got destroyed it created a ctnetlink event, causing an oops in
netlink_has_listeners when trying to use the destroyed nfnetlink
socket."

If nf_conntrack_netlink is loaded before ip_vs this is not a problem.

This patch simply avoids calling ip_vs_conn_drop_conntrack()
when netns is dying as suggested by Julian.

Signed-off-by: Hans Schillstrom <hans.schillstrom@xxxxxxxxxxxx>
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>

---
net/netfilter/ipvs/ip_vs_conn.c | 10 +++++++++-
net/netfilter/ipvs/ip_vs_core.c | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)

--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -776,8 +776,16 @@ static void ip_vs_conn_expire(unsigned l
if (cp->control)
ip_vs_control_del(cp);

- if (cp->flags & IP_VS_CONN_F_NFCT)
+ if (cp->flags & IP_VS_CONN_F_NFCT) {
ip_vs_conn_drop_conntrack(cp);
+ /* Do not access conntracks during subsys cleanup
+ * because nf_conntrack_find_get can not be used after
+ * conntrack cleanup for the net.
+ */
+ smp_rmb();
+ if (ipvs->enable)
+ ip_vs_conn_drop_conntrack(cp);
+ }

ip_vs_pe_put(cp->pe);
kfree(cp->pe_data);
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1965,6 +1965,7 @@ static void __net_exit __ip_vs_dev_clean
{
EnterFunction(2);
net_ipvs(net)->enable = 0; /* Disable packet reception */
+ smp_wmb();
__ip_vs_sync_cleanup(net);
LeaveFunction(2);
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/