Thread (6 messages) 6 messages, 2 authors, 2009-10-13

Re: [Bug #14301] WARNING: at net/ipv4/af_inet.c:154

flat view

From: Eric Dumazet <hidden>
Date: 2009-10-03 17:54:08
Also in: lkml

Eric Dumazet a écrit :
Eric Dumazet a écrit :
quoted
Rafael J. Wysocki a écrit :
quoted
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 [off-list ref]
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...

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help