On Sun, Mar 25, 2001 at 10:51:52PM -0500, [EMAIL PROTECTED] wrote:
> I was almost certain the following kernel oops occurred during packet
> capture.
> The packet received was an arp request. Kernel syslog indicated the kernel
> received the arp request. My application captures arp packet as well.
> The calls leading to the oops :
> pcap_dispatch ...
> sys_recvfrom ...
> kfree_skbmem ...free_block.
>
> The call stack of the oops is below. The oops does not happen all the time.
> However, there is a steady memory leak - Tops reported memory used by my
> pcap application is stable at 0.3%, but system memory usage keeps going up
> (reaching 250M used, 4M free before staying there).
>
> I am running Linux 2.4.0 kernel and libpcap-0.6.2. Does this look like a
> libpcap problem or skbmem problem? Does anyone recognize the problem?
>
> >>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>
It is almost certainly a kernel problem of some sort; I see little, if
any, reason to believe it couldn't be reproduced with, say, a program
that does the same sort of straightforward PF_PACKET-socket reading that
libpcap does. Perhaps there's some specific things that libpcap does
that cause a bad code path in the kernel to be followed, but the fact
that this can happen indicates that there *is* a bad code path in the
kernel....
Without a kernel crash dump and stack trace, I can't say much about
*why* it's happening - "free_block()" does
spin_lock(&cachep->spinlock);
__free_block(cachep, objpp, len);
spin_unlock(&cachep->spinlock);
and I don't know whether the problem is that "&cachep->spinlock" is
bogus or if the inline "__free_block()" routine blew up because the list
of objects passed to it to free is bogus.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
