Eric Dumazet a écrit : > Eric Dumazet a écrit : >> Rafael J. Wysocki a écrit : >>> This message has been generated automatically as a part of a report >>> of regressions introduced between 2.6.30 and 2.6.31. >>> >>> The following bug entry is on the current list of known regressions >>> introduced between 2.6.30 and 2.6.31. Please verify if it still should >>> be listed and let me know (either way). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14301 >>> Subject : WARNING: at net/ipv4/af_inet.c:154 >>> Submitter : Ralf Hildebrandt <Ralf.Hildebrandt@xxxxxxxxxx> >>> Date : 2009-09-30 12:24 (2 days old) >>> References : http://marc.info/?l=linux-kernel&m=125431350218137&w=4 >>> >>> >> If commit d99927f4d93f36553699573b279e0ff98ad7dea6 >> (net: Fix sock_wfree() race) doesnt fix this problem, then >> maybe we should take a look at an old patch. >> >> < data mining... running... output results to lkml/netdev > >> >> Random guesses >> >> 1) : commit d55d87fdff8252d0e2f7c28c2d443aee17e9d70f >> (net: Move rx skb_orphan call to where needed) >> >> A similar problem on SCTP was fixed by commit >> 1bc4ee4088c9a502db0e9c87f675e61e57fa1734 >> (sctp: fix warning at inet_sock_destruct() while release sctp socket) >> >> 2) CORK and UDP sockets >> It seems we can leave an UDP socket with a frame in sk_write_queue >> Purge of this queue is done by udp_flush_pending_frames() >> This calls ip_flush_pending_frames() >> But this function only calls kfree_skb(), not sk_wmem_free_skb()... >> >> >> Could you try following patch ? >> > > Hmm, I missed the ip_cork_release(), here is an updated version. > Please ignore this patch, I was wrong, sk_forward_alloc is not used on xmit side for udp, only receive side. CORK/UDP should be fine Investigation still needed... -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
