From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 22:22:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3642106564A for ; Mon, 10 Jan 2011 22:22:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 59E388FC1B for ; Mon, 10 Jan 2011 22:22:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8FAFgVK02DaFvO/2dsb2JhbACECJIzjwOtSo4QgSGDN3QEhGeGIw X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="104880046" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 Jan 2011 17:22:56 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 14614B403E for ; Mon, 10 Jan 2011 17:22:56 -0500 (EST) Date: Mon, 10 Jan 2011 17:22:56 -0500 (EST) From: Rick Macklem To: freebsd-stable@freebsd.org Message-ID: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Subject: important NFS client patch for FreeBSD8.n X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 22:22:56 -0000 I just commited a patch (r217242) to head. Anyone who is using client side NFS on FreeBSD8.n should apply this patch. It is also available at: http://people.freebsd.org/~rmacklem/krpc.patch It fixes a problem where the kernel rpc assumes that 4 bytes of data exists in the first mbuf without checking. If the data straddles multiple mbufs, it uses garbage and then a typical case will wedge for a minute or so until it times out and establishes a new TCP connection. It also replaces m_pullup() with m_copydata(), since m_pullup() can fail for rare cases when there is data available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail when mbuf allocation is constrainted, for example.) Thanks to john.gemignani at isilon.com for spotting this problem, rick