Re: System crash in tcp_fragment()

[george anzinger <george@mvista.com>]

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