From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 15 00:09:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3AF61065742 for ; Sat, 15 Jan 2011 00:09:24 +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 A0E1E8FC16 for ; Sat, 15 Jan 2011 00:09:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAP1zME2DaFvO/2dsb2JhbACECqFHrHaOMYEkgzd0BIRrhiuLNA X-IronPort-AV: E=Sophos;i="4.60,325,1291611600"; d="scan'208";a="105467904" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 14 Jan 2011 19:09:23 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B92B2B3F90; Fri, 14 Jan 2011 19:09:23 -0500 (EST) Date: Fri, 14 Jan 2011 19:09:23 -0500 (EST) From: Rick Macklem To: Daniel Braniss Message-ID: <334773590.270506.1295050163687.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: 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) Cc: freebsd-hackers@freebsd.org Subject: Re: NFS: file too large X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 00:09:25 -0000 > > BTW, why not make away with the test altogether? > Well, since a server specifies the maximum file size it can handle, it seems good form to check for that in the client. (Although I'd agree that a server shouldn't crash if a read/write that goes beyond that limit.) Also, as Matt notes, off_t is signed. As such, it looks to me like the check could mess up if uio_offset it right near 0x7fffffffffffffff, so that uio->ui_offset + uio->uio_resid ends up negative. I think the check a little above that for uio_offset < 0 should also check uio_offset + uio_resid < 0 to avoid this. rick