Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5211484ybf; Wed, 4 Mar 2020 19:46:52 -0800 (PST) X-Google-Smtp-Source: ADFU+vsv30n1F+ltWOQnn/R9RgMwSfBYsY97DmESca58jjr49WPZlfs5/RiVxeBuT/FVzQe1g76h X-Received: by 2002:a54:4181:: with SMTP id 1mr4059163oiy.61.1583380012757; Wed, 04 Mar 2020 19:46:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583380012; cv=none; d=google.com; s=arc-20160816; b=f/Rxq/BHq+eOOEhPxpDv8WIhiWj9htANQDKB5tEVnjVO/AfGP2nojBUznM0DQ9id27 T+wKErej3b2K8sYoFtIFk8Yx2H3jxocv5psSSHF9kg3lE+vL0mYQEHaVv8SsIjh5ZNRQ QTqnnmosdzhMvwpmRc6EmiVmiFMUEjSHfiLXHXbXwgxQsiDfF/FTYiT3uL7hX7YhD6YZ l4OUCmMl4gNAhuD3unSVMFDYoPrWljAB19K5Y+NxWqU78WnvywjB/XYtDjIBl/FzFDV3 pdPavRj9dUt/VAYHrIB4pX47jYGzs8VnOfqJOOCxJwphsChO/iX4OIjjON/dxNzKWqf8 pSLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=8nG1dqTs+CyPQ+yn+nxeD6/J3CIEaOsD9CG74a0LiZM=; b=g1GINeV7f6OHrdexjaFLSe3wBxEvEmy74lKgtNePgBW3osVHfcGJsbJr1yJwFKNCDj wYB8gjmp8z75r4rI1nyHjRgcR4McE1YmlpWpBmts3Zmc39jZctQ4QQGhtWyfMx/kDXfD aE3oTQeufF7pPKPr++4rTpR2CJUb91+nOqXrnd3hkTM2W1lVyEhHrLGXXRTLRFGbXn/w wcY/jD69wM6Zsfdp6tClYvsd22+O2pBkT5dolOjcz9ScwVYiv5YRc8Y6DFh2PrFihFbD aiVz8bH5LHV118fJBHFQA9S+w3NsqbcKKsJbotrZsktup5KZDEa1b0acUcdI6+O7ZyUd efDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h18si2450807otr.265.2020.03.04.19.46.26; Wed, 04 Mar 2020 19:46:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725844AbgCEDqW (ORCPT + 99 others); Wed, 4 Mar 2020 22:46:22 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:35802 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725776AbgCEDqW (ORCPT ); Wed, 4 Mar 2020 22:46:22 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 794E7EBDBB5B7903EDA3; Thu, 5 Mar 2020 11:46:20 +0800 (CST) Received: from [127.0.0.1] (10.173.223.234) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Thu, 5 Mar 2020 11:46:18 +0800 Subject: Re: [PATCH] nfsd: Fix build error To: Bruce Fields , Chuck Lever References: <20200304131803.46560-1-yuehaibing@huawei.com> <20200304200609.GA26924@fieldses.org> CC: Olga Kornievskaia , Linux NFS Mailing List , From: Yuehaibing Message-ID: Date: Thu, 5 Mar 2020 11:46:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20200304200609.GA26924@fieldses.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.223.234] X-CFilter-Loop: Reflected Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 2020/3/5 4:06, Bruce Fields wrote: > On Wed, Mar 04, 2020 at 01:00:12PM -0500, Chuck Lever wrote: >> Hi- >> >>> On Mar 4, 2020, at 8:18 AM, YueHaibing wrote: >>> >>> fs/nfsd/nfs4proc.o: In function `nfsd4_do_copy': >>> nfs4proc.c:(.text+0x23b7): undefined reference to `nfs42_ssc_close' >>> fs/nfsd/nfs4proc.o: In function `nfsd4_copy': >>> nfs4proc.c:(.text+0x5d2a): undefined reference to `nfs_sb_deactive' >>> fs/nfsd/nfs4proc.o: In function `nfsd4_do_async_copy': >>> nfs4proc.c:(.text+0x61d5): undefined reference to `nfs42_ssc_open' >>> nfs4proc.c:(.text+0x6389): undefined reference to `nfs_sb_deactive' >>> >>> Add dependency to NFSD_V4_2_INTER_SSC to fix this. >>> >>> Fixes: ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy") >>> Signed-off-by: YueHaibing >>> --- >>> fs/nfsd/Kconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig >>> index f368f32..fc587a5 100644 >>> --- a/fs/nfsd/Kconfig >>> +++ b/fs/nfsd/Kconfig >>> @@ -136,6 +136,7 @@ config NFSD_FLEXFILELAYOUT >>> >>> config NFSD_V4_2_INTER_SSC >>> bool "NFSv4.2 inter server to server COPY" >>> + depends on !(NFSD=y && NFS_FS=m) >> >> The new dependency is not especially clear to me; more explanation >> in the patch description about the cause of the build failure >> would definitely be helpful. >> >> NFSD_V4 can't be set unless NFSD is also set. >> >> NFS_V4_2 can't be set unless NFS_V4_1 is also set, and that cannot >> be set unless NFS_FS is also set. >> >> So what's really going on here? > > I don't understand that "depends" either. > > The fundamental problem, though, is that nfsd is calling nfs code > directly. Yes > > Which I noticed in earlier review and then forgot to follow up on, > sorry. > > So either we: > > - let nfsd depend on nfs, fix up Kconfig to reflect the fact, or It only fails while NFSD=y && NFS_FS=m, other cases works fine as Chuck Lever pointed. > - write some code so nfsd can load nfs and find those symbols at > runtime if it needs to do a copy. > > The latter's certainly doable, but it'd be simplest to do the former. > Are there actually a lot of people who want nfsd but not nfs? Does that > cause a real problem for anyone? > > --b. > > . >