On 2013/02/19 00:52, Pablo Neira Ayuso wrote: > On Mon, Feb 18, 2013 at 11:57:36AM +0800, Gao feng wrote: > [...] >>> I think this is very unlikely to happen. The removal of the module >>> happens in user-context and the entire path to build and deliver the >>> skb to user-space is protected is under spin_lock_bh, so scheduling >>> is not possible. >> >> Doesn't spin_lock_bh only disable local cpu's bottom-half? >> the task that remove the modules can run on other cpus at the same time. >> I'm wrong? > > That's right. But that will not happen since the removal of ipt_ULOG > is protected by the module refcount, which is bumped for each iptables > rule. So, you have to remove all rules using the ULOG target first to > be able to rmmod that module, but then there is no chance to race with > packets. this calltrack doesn't add the refcount of moudule. trace_packet->nf_log_packet->logger->logfn(ipt_logfn). But when removing module,we call nf_log_unregister and we can make sure only ulog_tg_exit uses ulog_buffer->skb, So it's safe to don't add spin lock protect here. I will send a v2 patchset to remove the spin lock protect in ebt_ulog module. Thanks! -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
