From owner-freebsd-current  Sun May 31 23:25:15 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id XAA09398
          for freebsd-current-outgoing; Sun, 31 May 1998 23:25:15 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09382;
          Sun, 31 May 1998 23:25:12 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id QAA13930;
	Mon, 1 Jun 1998 16:24:47 +1000
Date: Mon, 1 Jun 1998 16:24:47 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199806010624.QAA13930@godzilla.zeta.org.au>
To: dg@root.com, scrappy@hub.org
Subject: Re: May29th kernel with May20th CAM drivers: panic?
Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>   It appears that the mbuf chain is getting corrupted somehow. The above
>trap info indicates that the m_data pointer is bogus, resulting in a panic
>when the system attempts to get the physical address from the page tables.
>I don't see anything obvious in the 'de' driver that could cause this, so
>I suspect the buffer corruption is external to the driver.

I recently fixed one source of mbuf chain corruption:

diff -c2 uipc_socket.c~ uipc_socket.c
*** uipc_socket.c~	Sun May 17 04:45:15 1998
--- uipc_socket.c	Thu May 28 14:21:40 1998
***************
*** 689,694 ****
  		orig_resid = 0;
  		if (psa)
! 			*psa = dup_sockaddr(mtod(m, struct sockaddr *),
! 					    mp0 == 0);
  		if (flags & MSG_PEEK) {
  			m = m->m_next;
--- 689,693 ----
  		orig_resid = 0;
  		if (psa)
! 			*psa = dup_sockaddr(mtod(m, struct sockaddr *), 0);
  		if (flags & MSG_PEEK) {
  			m = m->m_next;

It is apparently not OK for the MALLOC() in dup_sockaddr() to wait if the
call is from here.  Even lowering the ipl is not OK.  To see corruption,
add a reverse splx()/splnet() here and do a `ping -f' to an ethernet host.
This normally causes a panic in sbdrop() within a second or two.  OTOH,
the reverse splx()/splnet() doesn't seem to cause any problems under
light network loads, and MALLOC() doesn't normally sleep, so this bug
probably only shows up under very heavy loads.

Bruce

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