Re: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors

[Keith Owens]

"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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/