I received note from Tommi Saviranta with bug information which is copied below. One bug we had recently (reported by Florian Westphal), I attach my patch for it (having observed the same thing at home); now there is a third occurrence. I believe we should fix this soon. 1. Write queue not empty ------------------------ | "KERNEL: assertion (skb_queue_empty(&sk->sk_write_queue)) | failed at net/core/stream.c (276)" in system log. I observed this also at some time - but with TCP. 2. Out-of-order segments ------------------------ | At some point I've also had the following line in syslog, possibly | related to failing full duplex: | | dccp_check_seqno: DCCP: Step 6 failed for ACK packet, | (LSWL(194687531369580) <= P.seqno(194687531369777) <= S.SWH(194687531369679)) | and (P.ackno exists | or LAWL(195643175609843) <= P.ackno(195643175713728) <= S.AWH(195643175713921), | sending SYNC... Ian observed this in December - the most recent occurrence was the Sync-flood fixes (which will be resubmitted soon). 3. Memory allocation while in atomic context (the bug) ------------------------------------------------------ | At worst case scenario, such as when running iperf, | host2% ./iperf --protocol DCCP -l 500 -c 192.168.1.1 -p 5001 -t 60 | results in kernel panic which totally kills networking: | | <snip> | CCID: Registered CCID 2 (ccid2) | BUG: sleeping function called from invalid context at mm/slab.c:3035 | in_atomic():1, irqs_disabled():0 | [<c046ede5>] __kmalloc+0x42/0x7d | [<e0ae106b>] ccid2_hc_tx_alloc_seq+0x23/0xa4 [dccp_ccid2] | [<e0ae13d8>] ccid2_hc_tx_packet_sent+0x8d/0x13f [dccp_ccid2] | [<e0ae134b>] ccid2_hc_tx_packet_sent+0x0/0x13f [dccp_ccid2] | [<e0b2f13f>] dccp_write_xmit+0x20e/0x2c4 [dccp] | [<c0439d17>] hrtimer_run_queues+0x127/0x141 | [<e0b2f813>] dccp_write_xmit_timer+0x0/0x51 [dccp] | [<e0b2f846>] dccp_write_xmit_timer+0x33/0x51 [dccp] | [<c042e51b>] run_timer_softirq+0x101/0x164 | [<c05c296f>] net_rx_action+0xca/0x185 | [<c042b7b0>] __do_softirq+0x5d/0xba | [<c040615b>] do_softirq+0x59/0xb1 | [<c0450189>] handle_level_irq+0x0/0xdf | [<c0406279>] do_IRQ+0xc6/0xdd | [<c04048f3>] common_interrupt+0x23/0x28 | [<c04200d8>] find_busiest_group+0x1d2/0x4c3 | [<c05b9aff>] lock_sock_nested+0x20/0xa3 | [<c04ed070>] copy_from_user+0x3a/0x66 | [<e0b3083f>] dccp_sendmsg+0x2c/0x156 [dccp] | [<c05ff51d>] inet_sendmsg+0x3b/0x45 | [<c05b74b5>] sock_aio_write+0xf9/0x105 | [<c04720ad>] do_sync_write+0xc7/0x10a | [<c0437725>] autoremove_wake_function+0x0/0x35 | [<c0472900>] vfs_write+0xbc/0x154 | [<c0472f07>] sys_write+0x41/0x67 | [<c0403f64>] syscall_call+0x7/0xb | ======================= | </snip> | This was observed first on http://www.mail-archive.com/dccp@xxxxxxxxxxxxxxx/msg01811.html A patch is attached - Arnaldo came up with an independent solution. - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
