Messages in this thread | | | From | Keith Owens <> | Subject | Re: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors | Date | Thu, 12 Jan 2006 16:38:03 +1100 |
| |
"Paul E. McKenney" (on Wed, 11 Jan 2006 21:04:53 -0800) wrote: >On Thu, Jan 12, 2006 at 02:29:52PM +1100, Keith Owens wrote: >> An alternative patch that requires no locks and does not even require >> RCU is in http://marc.theaimsgroup.com/?l=linux-kernel&m=113392370322545&w=2 > >But doesn't notifier_call_chain_lockfree() need to either disable >preemption or use atomic operations to update notifier_chain_lockfree_inuse[] >in order to avoid problems with preemption?
Yes it does :(. Originally the atomic notifier chains were only called from atomic contexts (typically interrupt context), but if they are going to be generalized to all contexts, then the code is not good enough. These lines either assume no preemption or that preemption is stacked in LIFO order, which is not guaranteed.
int notifier_call_chain_lockfree(struct notifier_block **list, unsigned long val, void *v) { int ret = NOTIFY_DONE, cpu = smp_processor_id(), nested; struct notifier_block *nb; nested = notifier_chain_lockfree_inuse[cpu]; notifier_chain_lockfree_inuse[cpu] = 1; wmb(); nb = *list; while (nb) { smp_read_barrier_depends(); ret = nb->notifier_call(nb, val, v); if (ret & NOTIFY_STOP_MASK) break; nb = nb->next; } barrier(); notifier_chain_lockfree_inuse[cpu] = nested; return ret; }
So either disable preemption in notifier_call_chain_lockfree (including all the callbacks that it invokes) or notifier_chain_lockfree_inuse has to be an atomic_t. atomic_t would be better, but it could cause a problem on architectures that implement atomic_t via hashed spinlocks _and_ have non maskable interrupts that call notifier_call_chain_lockfree().
Going away to think about this ...
- 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/
| |