From owner-freebsd-net@FreeBSD.ORG  Thu Oct 23 17:27:24 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6C4AD16A4B3
	for <freebsd-net@freebsd.org>; Thu, 23 Oct 2003 17:27:24 -0700 (PDT)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by mx1.FreeBSD.org (Postfix) with SMTP id 37DE443F93
	for <freebsd-net@freebsd.org>; Thu, 23 Oct 2003 17:27:23 -0700 (PDT)
	(envelope-from iedowse@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa46705@salmon>; 24 Oct 2003 01:27:22 +0100 (BST)
To: Sam Leffler <sam@errno.com>
In-Reply-To: Your message of "Thu, 23 Oct 2003 14:41:36 PDT."
             <200310231441.36966.sam@errno.com> 
Date: Fri, 24 Oct 2003 01:27:20 +0100
From: Ian Dowse <iedowse@maths.tcd.ie>
Message-ID: <200310240127.aa46705@salmon.maths.tcd.ie>
cc: freebsd-net@freebsd.org
Subject: Re: anyone believe this KASSERT? 
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Oct 2003 00:27:24 -0000

In message <200310231441.36966.sam@errno.com>, Sam Leffler writes:
>uipc_socket.c has a KASSERT in soreceive that I think is wrong.  It dates from
> 
>a long time ago but I can't tell exactly who created it since some 
>intermediate munging buggered the CVS logs.

It was there in revision 1.1 as:

	m = so->so_rcv.sb_mb;
	...
	if (m == 0 || (...) &&
	    m->m_nextpkt == 0 && (pr->pr_flags & PR_ATOMIC) == 0) {
#ifdef DIAGNOSTIC
		if (m == 0 && so->so_rcv.sb_cc)
			panic("receive 1");
#endif

Seems to be clearer there except for the lack of brackets around
the (a && b && c) - it's just saying that if sb_mb is NULL then
sb_cc should be zero. The current code appears to do the same thing,
so looks reasonable unless I'm missing something (sb_mb should be
NULL when there is no data queued shouldn't it?).

Digging back even further:

REV:7.13                uipc_socket.c       1989/04/22 12:26:53       sklower

   checkpoint for version to be handed to NIST, simple tp4 connection

...
-       if (so->so_rcv.sb_cc == 0) {
+       m = so->so_rcv.sb_mb;
+       if (m == 0) {
+               if (so->so_rcv.sb_cc)
+                       panic("receive 1");

Ian