Re: [PATCH] Fix ipt_ULOG panics on SMP kernels

[Patrick McHardy <kaber@trash.net>]

Mark Huang wrote:
> I've run into the same kernel panic as these reports:
> 
> 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
> 
> 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,
> implemented by the attached patch, is to just return from ulog_send() if
> ub->skb
> is null.

Very nice catch, thank you. The second solution is perfectly fine I
think, if the skb has already been sent there is no need to do
anything, a new allocation could be useless if no further traffic
arrives. If you could add a similar fix to
net/bridge/netfilter/ebt_ulog.c and net/netfilter/nfnetlink_log.c
and send me a Signed-off-by: line I'll push it in 2.6.18. Thanks.