Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Apr 2001 08:00:13 -0700 (PDT)
From:      Stas Kisel <stask@tiger.unisquad.com>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/24608: FreeBSD 4.2 Panics in Realtek rl driver
Message-ID:  <200104121500.f3CF0DY97211@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/24608; it has been noted by GNATS.

From: Stas Kisel <stask@tiger.unisquad.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc: myleal@spliceip.com.br
Subject: Re: kern/24608: FreeBSD 4.2 Panics in Realtek rl driver
Date: Thu, 12 Apr 2001 17:52:24 +0300

 Hi.
 
 You probably forgot about this issue. Think it is gone? Negative.
 BTW, I've reinstalled 4.2-RELEASE (because of HDD fault. And I didn't post
 results that day because if it - sorry).
 And there were no reboots during whole month when machine was proxy server.
 And machine reboots daily again when it became router, firewall, NAT and
 tarffic shaper.
 
 So, I've added several panic() calls to mbuf code. Don't laugh at it,
 please! I'm not familiar with the kernel and I'm just poking around
 in the hope that someone will take all this data and fix the bug.
 Panics are designed to occur when someone tries to assign wrong
 value to either mmbfree or mclfree. I believe values between
 0x5a000000 and 0x63000000 to be wrong. Correct me please.
 Code is at http://tiger.unisquad.com/~stask/rl/mbuf_panics.diff
 
 And one of these panics was triggered!
 Whole typescript is at http://tiger.unisquad.com/~stask/rl/typescript.19-20,
 along with another case when some_mbuf->m_next was invalid too.
 So, I have almost nothing interesting:
 
 1. This time mmbfree is spoiled in MGETHDR(), in sosend() at
 ../../kern/uipc_socket.c:555
 2. Wrong value for mmbfree was taken from mmbfree->m_next.
 3. Here is the offending mbuf:
 (kgdb) p *mmbfree
 $3 = {m_hdr = {mh_next = 0x5ac08d00, mh_nextpkt = 0x0, 
                          ^^^^^^^^^^ - here is wrong value
     mh_data = 0xc05c95f0 "", mh_len = 14, mh_type = 0, mh_flags = 2}, M_dat = {
     MH = {MH_pkthdr = {rcvif = 0xc05a6400, len = 1490, header = 0xc6dfc780, 
         csum_flags = 0, csum_data = 16, aux = 0x0}, MH_dat = {MH_ext = {
           ext_buf = 0xc05e0000 "k/clickbanner.asp?id=88&page=7&btype=2&bstype=1&rnd='+rnd+'\" target=_top>'+\r\n'<img src=\"http://www.sle.com.ua:8000/?88?7?2?'+rnd+'?1\" alt=\"SLE Banner Network\" width=120 height=60 border=0 ismap></a>')"..., ext_free = 0, ext_size = 2048, ext_ref = 0}, 
         MH_databuf = "\000\000^ I skip the rest of junk because it might kill someone's mailreader. You can find it at above URL"...}}, 
     M_databuf = "\000dZ And this I skip too"...}}
 
 Simple grep '->m_next = ' on kernel source gave me 177 results and I'm
 afraid I have to add 177 panics to the kernel. And I'm afraid ever more that
 my grep missed some, say '->m_next += ' or '->m_next  = '.
 
 Any advise is welcome. Ever advise to post all data here instead of URLs :)
 Thank you.
 
 \bye
 Stas
 
 
 On Mon, Feb 12, 2001 at 06:18:23PM +0000, stask@tiger.unisquad.com wrote:
 > 
 > Hi.
 > 
 > It looks like kmem_malloc() is not the one who returns wrong pointer
 > to m_mballoc(), but it is one of MGET()/MGETHDR()/MFREE() spoiling mmbfree,
 > and thus MGET()/MGETHDR() return wrong pointer in various places.
 > 
 > I've added ever more logging to see who of them is the killer, and I'll
 > post results tomorrow.
 > 
 > \bye
 > Stas
 > 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104121500.f3CF0DY97211>