Ingo Molnar wrote:
> running an "isic" stresstest on and against a testbox [which, amongst 
> other things, generates random incoming and outgoing packets] on 
> 2.6.17-rc3 (and 2.6.17-rc3-mm1) over gigabit results in a reproducible 
> lockup, after 5-10 minutes of runtime:
> 
> BUG: soft lockup detected on CPU#0!
>  [<c0104e7f>] show_trace+0xd/0xf
>  [<c0104e96>] dump_stack+0x15/0x17
>  [<c015ad02>] softlockup_tick+0xc5/0xd9
>  [<c0134c02>] run_local_timers+0x22/0x24
>  [<c0134fb7>] update_process_times+0x40/0x65
>  [<c011aa56>] smp_apic_timer_interrupt+0x58/0x60
>  [<c010492b>] apic_timer_interrupt+0x27/0x2c
>  [<c0f00df9>] sctp_new+0x8b/0x235
>  [...]
> 
> this is with FRAME_POINTERS enabled, so it's an exact stacktrace.
> 
> the lockup is at:
> 
> (gdb) list *0xc0f00df9
> 0xc0f00df9 is in sctp_new 
> (net/ipv4/netfilter/ip_conntrack_proto_sctp.c:444).
> 439
> 440             sh = skb_header_pointer(skb, iph->ihl * 4, sizeof(_sctph), &_sctph);
> 441             if (sh == NULL)
> 442                     return 0;
> 443
> 444             if (do_basic_checks(conntrack, skb, map) != 0)
> 445                     return 0;
> 446
> 447             /* If an OOTB packet has any of these chunks discard (Sec 8.4) */
> 448             if ((test_bit (SCTP_CID_ABORT, (void *)map))
> 
> most likely somewhere within do_basic_checks(). [whose stack entry is 
> obscured by the irq entry, so it's not in the stackdump.] I have SCTP 
> turned on:

Yes, it seems like it doesn't make any forward progress in
for_each_sctp_chunk() because the chunk length is zero. Can
you try this patch please?