From owner-svn-src-all@FreeBSD.ORG Sun Dec 28 07:16:49 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6507F8B; Sun, 28 Dec 2014 07:16:49 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91E0664E15; Sun, 28 Dec 2014 07:16:49 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id sBS7GnPe085222; Sun, 28 Dec 2014 07:16:49 GMT (envelope-from peterj@FreeBSD.org) Received: (from peterj@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id sBS7GnPB085221; Sun, 28 Dec 2014 07:16:49 GMT (envelope-from peterj@FreeBSD.org) Message-Id: <201412280716.sBS7GnPB085221@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: peterj set sender to peterj@FreeBSD.org using -f From: Peter Jeremy Date: Sun, 28 Dec 2014 07:16:49 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-9@freebsd.org Subject: svn commit: r276328 - stable/9/sys/fs/nfs X-SVN-Group: stable-9 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 07:16:49 -0000 Author: peterj Date: Sun Dec 28 07:16:48 2014 New Revision: 276328 URL: https://svnweb.freebsd.org/changeset/base/276328 Log: MFH r275941: Adjust the test of a KASSERT to better match the intent. This assertion was added in r246213 as a guard against corrupted mbufs arriving from drivers, the key distinguishing factor of said mbufs being that they had a negative length. Given we're in a while loop specifically designed to skip over zero-length mbufs, panicking on a zero-length mbuf seems incorrect. Suggested by: rmacklem MFH go-ahead: benno Approved by: grog (co-mentor) Modified: stable/9/sys/fs/nfs/nfs_commonsubs.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/fs/ (props changed) Modified: stable/9/sys/fs/nfs/nfs_commonsubs.c ============================================================================== --- stable/9/sys/fs/nfs/nfs_commonsubs.c Sun Dec 28 07:14:38 2014 (r276327) +++ stable/9/sys/fs/nfs/nfs_commonsubs.c Sun Dec 28 07:16:48 2014 (r276328) @@ -200,7 +200,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, } mbufcp = NFSMTOD(mp, caddr_t); len = mbuf_len(mp); - KASSERT(len > 0, ("len %d", len)); + KASSERT(len >= 0, + ("len %d, corrupted mbuf?", len)); } xfer = (left > len) ? len : left; #ifdef notdef