kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > Is is possible for the other cpu (or even this one given the > > ksoftirqd stuff) to remove or alter the skb that > > tcp_fragment() is processing? > > No. > > What locks, if any, are needed to prevent this. > > They are already applied. > > Looking at the last lines of the bugzilla thread, I see the answer: > > > - Observation, the BUG_TRAP assertion likely should have done something better > > than just report the condition, wonder if an earlier panic or other corrective > > action may have kept the TCP stack moving instead of the oops? Looks lazy to > > me... > > Well, add BUG() to BIG_TRAP() to oops it earlier. Maybe this will move > you closer to real problem. Right. Will do. > > And also your reasoning about smp_processor_id() sounds strange, > preemption code must reschedule thread preemted in the kernel to the > same cpu, it is enough to avoid troubles with this. That (ahem) hack was tried and rejected by the powers that be. I admit that is it more work to find the resulting problems, but the fixes seem to be easy and do not to add to overhead, at least thus far. > > Alexey -- 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
