kuznet@xxxxxxxxxxxxx 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@xxxxxxxxxx
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
|