lkml.org 
[lkml]   [2001]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectoops during kfree_skbmem
I am reposting... the oops call stack didn't show up correctly.

>>EIP; c012c504 <free_block+84/d8> <=====
Trace; c011b77a <do_softirq+5a/88>
Trace; c012c82a <kfree+72/98>
Trace; c01d00fd <kfree_skbmem+25/80>
Trace; c01d024b <__kfree_skb+f3/f8>
Trace; c01d0d1d <skb_free_datagram+1d/24>
Trace; c0203a61 <packet_recvmsg+139/148>
Trace; c01cd441 <sock_recvmsg+41/b0>
Trace; c0203928 <packet_recvmsg+0/148>
Trace; c01ce2fd <sys_recvfrom+ad/108>

The oops happened on a box running Linux 2.4.0 and libpcap-0.6.2 (which uses
AF_PACKET socket). The packet received was an arp request. I have syslog indicating
the kernel received the arp request. My pcap application captures arp packet as well.
The calls leading to the oops :
pcap_dispatch ...
sys_recvfrom ...
kfree_skbmem ...free_block.

The oops is not recreatable on demand. However, on another box running 2.4.0-test7,
there is a memory leak. Top reports memory used by my application stable at 0.3%,
but system memory usage keeps going up (reaching 250M used, 4M free before staying there).

Allen Lau

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:21    [W:0.021 / U:1.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site