From owner-freebsd-current@FreeBSD.ORG Thu May 21 14:53:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F42C1065687; Thu, 21 May 2009 14:53:19 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 0C82F8FC26; Thu, 21 May 2009 14:53:18 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by itchy.rabson.org (Postfix, from userid 80) id 1031E5DBA; Thu, 21 May 2009 15:53:56 +0100 (BST) To: Sam Leffler MIME-Version: 1.0 Date: Thu, 21 May 2009 15:53:56 +0100 From: Doug Rabson In-Reply-To: <4A156630.5080507@freebsd.org> References: <4A1460A3.2010202@freebsd.org> <4A156630.5080507@freebsd.org> Message-ID: X-Sender: dfr@rabson.org User-Agent: RoundCube Webmail/0.2.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: Andre Oppermann , rmacklem@uoguelph.ca, Robert Watson , freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 14:53:20 -0000 On Thu, 21 May 2009 07:33:20 -0700, Sam Leffler wrote: > Doug Rabson wrote: >> On Thu, 21 May 2009 11:36:49 +0100 (BST), Robert Watson >> wrote: >> >>> On Wed, 20 May 2009, Robert Watson wrote: >>> >>> >>>> On Wed, 20 May 2009, Andre Oppermann wrote: >>>> >>>> >>>>> While working on an optimized soreceive_stream() function [1] and >>>>> checking >>>>> the code how it is used I've come across quite a bit of code >>>>> >> duplication >> >>>>> in >>>>> the various NFS directories. >>>>> >>>>> Socket (read) operations are handled multiple times in a very similar >>>>> manner in these places: >>>>> >>>> My recommendation would be to do this analysis against the new NFS >>>> >> client >> >>>> and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, >>>> >> which >> >>>> is >>>> the NFSv234 implementation. Note in particular that in the new world >>>> order >>>> there's a centralize RPC implementation. >>>> >>>> The code you're looking at is a blend of the old NFSv23 client/server >>>> (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if >>>> >>>> which are on a gradual de-orbit burn. >>>> >>> After re-reading this e-mail, I realize that I'd mislabeled src/sys/rpc >>> >> as >> >>> being only used by the old code -- this is in fact not the case, it's >>> >> also >> >>> used by the new code. >>> >> >> Everything in src/sys/rpc except rpcclient.[ch] is part of the new RPC >> transport. The files rpcclient.c and rpcclient.h are part of the old >> broken >> NFSv4 client which is scheduled for removal. >> >> There is older RPC transport code in src/sys/nfsclient and >> src/sys/nfsserver which is currently used if the user uses the >> NFS_LEGACYRPC option. This too should be removed before 8.0 ships. >> > > NFS_LEGACYRPC is the only code that works reliably for me on xscale (BE > arm). The new code randomly causes alignment faults. I've not had time > to track down this problem but gonzo@ also reported this problem on mips > and I believe sent you a line# and stack trace of a fault. Until this > problem is fixed removing legacy support cannot happen. I'm aware of this one but I'm not exactly certain where the problem is. I did spend some time dredging through email archives trying to find out without success. I have a good idea where the bug is but I'd like to see at least one stacktrace or similar which confirms my suspicion before I commit a fix. When I get home, I'll take another look and see if I can find your original report. I'm certainly not going to be removing the NFS_LEGACYRPC option until this is fixed.