Messages in this thread | | | Date | Tue, 21 Apr 2009 13:34:51 +0800 | From | Lai Jiangshan <> | Subject | Re: [PATCH] netfilter: use per-cpu recursive lock (v11) |
| |
Eric Dumazet wrote: > Lai Jiangshan a écrit : >> Stephen Hemminger wrote: >>> +/** >>> + * xt_table_info_rdlock_bh - recursive read lock for xt table info >>> + * >>> + * Table processing calls this to hold off any changes to table >>> + * (on current CPU). Always leaves with bottom half disabled. >>> + * If called recursively, then assumes bh/preempt already disabled. >>> + */ >>> +void xt_info_rdlock_bh(void) >>> +{ >>> + struct xt_info_lock *lock; >>> + >>> + preempt_disable(); >>> + lock = &__get_cpu_var(xt_info_locks); >>> + if (likely(++lock->depth == 0)) >> Maybe I missed something. I think softirq may be still enabled here. >> So what happen when xt_info_rdlock_bh() called recursively here? > > well, first time its called, you are right softirqs are enabled until > the point we call spin_lock_bh(), right after this line : > >
Which context can enter the critical region? Can irq and softirq? or softirq only?
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |