Nivedita Singhvi wrote: > > On Mon, 20 May 2002, David S. Miller wrote: > > > Such rule does not even make this piece of code legal. Consider: > > > > task1:cpu0: x = counters[smp_processor_id()]; > > cpu0: PREEMPT > > task2:cpu0: x = counters[smp_processor_id()]; > > task2:cpu0: counters[smp_processor_id()] = x + 1; > > cpu0: PREEMPT > > task1:cpu0: counters[smp_processor_id()] = x + 1; > > full garbage > > > > But it does bring up important point, preemption people need to > > fully audit entire networking. > > > > It is totally broken by preemption the more I think about it. > > > > At the very beginning, all the SNMP counter bumping tricks will > > totally fail with preemption enabled. May be someone could tell me if these matter. If you are bumping a counter and you switch cpus in the middle, a.) does it matter? and b.) if so which cpu should get the count? I sort of thought that, if this were going on, it did not really matter as long as some counter was bumped. > > > > A lot of the synchronization between process context and interrupt > context is based on per-cpu data structures or simple locks > (without disabling irq's globally) eg: > > softnet_data queue (we only disable local interrupts), and > synchronization between tcp_readmsg() and tcp_rcv() over > the receive queue would get confused (lock.users flag would > be different on another CPU).. Disabling local interrupts also disables preemption, as does interrupt context. > > Wonder how any of it could possibly work.. It seems to take a LOT of work to break it. Even then, I think this problem at hand is in the driver (a new one from the intel folks). -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
