From owner-cvs-all  Thu Jul 29 14:43:36 1999
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3EC1E151AC; Thu, 29 Jul 1999 14:43:30 -0700 (PDT)
	(envelope-from wpaul@FreeBSD.org)
Received: (from wpaul@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id OAA83582;
	Thu, 29 Jul 1999 14:42:59 -0700 (PDT)
	(envelope-from wpaul@FreeBSD.org)
Message-Id: <199907292142.OAA83582@freefall.freebsd.org>
From: Bill Paul <wpaul@FreeBSD.org>
Date: Thu, 29 Jul 1999 14:42:58 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/nfs nfs_serv.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

wpaul       1999/07/29 14:42:58 PDT

  Modified files:
    sys/nfs              nfs_serv.c 
  Log:
  Correct the sanity test length calculation in nfsrv_readdirplus(): len is
  being incremented by 4 bytes too few each time through the loop, which
  allows more data into the mbuf chain that we really want. In the worst
  case, when we're using 32K read/write sizes with a TCP client, this causes
  readdirplus replies to sometimes exceed NFS_MAXPACKET which leads to a
  panic. This problem cropped up for me using an IRIX 6.5.4 NFSv3 TCP client
  with 32K read/write sizes, however supposedly it can be triggered by
  WinNT NFS servers too. In theory, it can probably be triggered by any
  NFS v3 implementation using TCP as long as it's using the maxiumum block
  size.
  
  Reviewed by: Matthew Dillon <dillon@backplane.com>
  
  Revision  Changes    Path
  1.83      +2 -2      src/sys/nfs/nfs_serv.c



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