From: Mark Huang <mlhuang@cs.princeton.edu>
Date: Thu, 10 Aug 2006 17:50:14 +0000 (+0000)
Subject: https://lists.gnumonks.org/pipermail/ulogd/2005-August/000776.html
X-Git-Tag: before-fedora-2_6_18-1_2239_FC5-vs2_0_2_2-rc6-merge~26
X-Git-Url: http://git.onelab.eu/?a=commitdiff_plain;h=fbd6a9fc5f730b783fda740357a6233a4e743cbd;p=linux-2.6.git

https://lists.gnumonks.org/pipermail/ulogd/2005-August/000776.html
http://lists.netfilter.org/pipermail/netfilter/2006-January/064509.html
https://lists.gnumonks.org/pipermail/ulogd/2006-April/000853.html

Fix kernel panic on various SMP machines. The culprit is a null ub->skb
in ulog_send(). I believe that this can occur for the following
reason. If ulog_timer() has already been scheduled on one CPU and is
spinning on the lock, and ipt_ulog_packet() flushes the queue on another
CPU by calling ulog_send() right before it exits (because the threshold
is reached), there will be no skbuff when ulog_timer() acquires the lock
and calls ulog_send(). Cancelling the timer in ulog_send() doesn't help
because it has already been scheduled and is running on the first CPU.

There are two solutions that I can see: re-allocate ub->skb at the end of
ipt_ulog_packet(), just like it does toward the beginning of the function. But
the problem will still happen if the allocation fails. The second solution,
is to just return from ulog_send() if ub->skb is null.
---

diff --git a/net/ipv4/netfilter/ipt_ULOG.c b/net/ipv4/netfilter/ipt_ULOG.c
index c84cc0338..f2b2171d3 100644
--- a/net/ipv4/netfilter/ipt_ULOG.c
+++ b/net/ipv4/netfilter/ipt_ULOG.c
@@ -120,6 +120,11 @@ static void ulog_send(unsigned int nlgroupnum)
 	if (ub->qlen > 1)
 		ub->lastnlh->nlmsg_type = NLMSG_DONE;
 
+	if (!ub->skb) {
+		DEBUGP("ipt_ULOG: ulog_send: nothing to send\n");
+		return;
+	}
+
 	NETLINK_CB(ub->skb).dst_group = nlgroupnum + 1;
 	DEBUGP("ipt_ULOG: throwing %d packets to netlink group %u\n",
 		ub->qlen, nlgroupnum + 1);