Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2566789pxb; Tue, 9 Mar 2021 06:00:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJwox/FLRzlwn8ZbA2PXgrVJC0UJFIxL79upkBoE0EDGnLU/8u6vYu4Zi/kMcMU+rKecW1W9 X-Received: by 2002:aa7:c345:: with SMTP id j5mr4152173edr.338.1615298407627; Tue, 09 Mar 2021 06:00:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615298407; cv=none; d=google.com; s=arc-20160816; b=sQSSBZUFdG2il1tsRozz2ExMqdH+neCTpqde4cip9myoWZWC+YtECJmIsJ7tehxAib xJyb6XDTsKfVGjRJ91psxWAOC0Jg5vo/spu3ihdNNMECqZLG6fMeSMXNUBuUoI45v5Hz TRiThI4HCBxtqHmk3PyoL9JwgK4N+H19rhXQMb5UjwMzeyWgxlCLrx6cS8nX4+3oBG72 jeaVlDmvRfEfBQ6ZdrDjAYKcVPWq91cENGgF4gzX8atgpsHfa1OoqKbCxS9h1/KKMKy5 BDwpclQOv/L4DboqbzmBVR1F14wlsC2Ep03fyH6NtDtHJS9zw+WFxdueZNu0aeBnvd+5 Ks/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Xw4prKFIV71j3r5FDBwxwDqhwqt4DbdRefFH2AydYfw=; b=dqKj7Lokv3r6eVe3aKQLqt0LSmGObQJ9U84tv35MjzCWXUxHGfbOgyNYmNZRc/hucD vmt89V/fKjfZ+BBdzXfprNi69/Jjzv+OSRQoWnI6KGQ2+msQ1wuBZG5ZkvZhQ04A65EQ h8XPiobeK8eaY10jeckxWo9IgKo4PnJRZMf4uEBNceSZsLpNnXpPSOdQFsh9E4oAY3d7 KdBbMQyFGmcA62B+jjx21/b5fMtQ6Oe39mrTf+nHLDdacMmcp7UE6RXsWtd5roQcVn8P nnik5gwwnkO+P8M/MVkmNigSOAoKcJQ8GcR3qY7bjrFaPwh5cjrO/GosfxmS6zeVjfP7 OtXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MqfqFIwf; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y17si9281781ejh.440.2021.03.09.05.59.35; Tue, 09 Mar 2021 06:00:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MqfqFIwf; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231660AbhCIN52 (ORCPT + 99 others); Tue, 9 Mar 2021 08:57:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230359AbhCIN5Z (ORCPT ); Tue, 9 Mar 2021 08:57:25 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B080C06174A for ; Tue, 9 Mar 2021 05:57:24 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id mj10so27897056ejb.5 for ; Tue, 09 Mar 2021 05:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xw4prKFIV71j3r5FDBwxwDqhwqt4DbdRefFH2AydYfw=; b=MqfqFIwfDH0yVdx1fT9GW5t9qjCO7m+z6cKng4k+nOaHoDRViaqdKeg6rlxDvtHUxM OlcuEv9KkfcQ8/L/igUF9zJgqUnjdIT4L1bmJKRky9wDrFfxkZ84sjsbaiBmpeJ/0fE3 8m7JqN3xzhS37LqW4DfHHAlhRokXukN1tRBT36ihFaDFji8zwILErQxmkslPPNaMPsuT uJP7vfDSwQ+otsuwJ2PQVvs+H9wBit7p/VeeggJXqKdcPYERveflp+0/+F64+lVMsFSW Srzqv2WEyfgha1PPfouyC1peTnidsQOYF6GB3WVjUxW7fipH9RO5FzRiOf9m2m+oa/Ip UIKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xw4prKFIV71j3r5FDBwxwDqhwqt4DbdRefFH2AydYfw=; b=GSqYkUIAHVsbTk7bhc0qMvCNziYqP/FHBfCU+d26JId8q5GlZAd6uoSrNtX84Kzfp1 OJo4PRssRW4qiH8SPhDeKh+lV1dHNIor0qzyHCrUYVH4sqbr1QU1Q4gaPqgn5nGL/59T OlYZVo/j9ztEmK3BFDnuMyrpdxZOWTHqTB4r4S1RBRwNazjcpolObkaZDENUcISl6v2/ aNQDlqzq2m6ynmby3jJmFmXYz5AwWYpgZxs0ORtHHZDCoBBiFzlytZ0hD3BMWCjXVBbS sMm1+xpnnWS2C9EK76cAd0tz5lvrIGYDx9sR/Fbjx0cNdQEhuUTsrfTg2sknIE30SW58 gFBA== X-Gm-Message-State: AOAM533YQMMfwLTiTs1b0/Q9tZQBr0FyP4V1OGo6c2IBSWHtlEucxKg1 pEqzoG1jlHin5TC9RHzPgC3mUfkxi1HPvjXdCt0= X-Received: by 2002:a17:906:30d9:: with SMTP id b25mr3059058ejb.348.1615298243178; Tue, 09 Mar 2021 05:57:23 -0800 (PST) MIME-Version: 1.0 References: <20210302194659.98563-1-dai.ngo@oracle.com> <4d18eb5e-b1b8-7f26-85b9-b6f9e1b1b231@oracle.com> In-Reply-To: <4d18eb5e-b1b8-7f26-85b9-b6f9e1b1b231@oracle.com> From: Olga Kornievskaia Date: Tue, 9 Mar 2021 08:57:11 -0500 Message-ID: Subject: Re: [PATCH] NFSv4.2: destination file needs to be released after inter-server copy is done. To: Dai Ngo Cc: Trond Myklebust , linux-nfs Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, Mar 8, 2021 at 3:10 PM wrote: > > Thanks Olga for reviewing the patch, reply inline below: > > On 3/8/21 10:35 AM, Olga Kornievskaia wrote: > > On Tue, Mar 2, 2021 at 2:47 PM Dai Ngo wrote: > >> This patch is to fix the resource leak problem of the source file > >> when doing inter-server copy. The fix is to close and release the > >> file in __nfs42_ssc_close after the copy is done. > >> > >> Signed-off-by: Dai Ngo > >> --- > >> fs/nfs/nfs4file.c | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c > >> index 57b3821d975a..20163fe702a7 100644 > >> --- a/fs/nfs/nfs4file.c > >> +++ b/fs/nfs/nfs4file.c > >> @@ -405,6 +405,12 @@ static void __nfs42_ssc_close(struct file *filep) > >> struct nfs_open_context *ctx = nfs_file_open_context(filep); > >> > >> ctx->state->flags = 0; > >> + > >> + if (!filep) > >> + return; > >> + get_file(filep); > >> + filp_close(filep, NULL); > >> + fput(filep); > >> } > > I don't understand this logic. There is no reason to call > > filp_close()? > > This is to follow the steps done in nfsd_file_put/.../nfsd_file_free. > However since this is the source file the flush is probably not needed, > just there to be safe. I will remove it. As I said before the only thing that's needed is the fput() which was originally in the code (but got incorrectly changed to nfsd_put()). I prefer to keep it there because this deals with cleaning up the SSC state. I don't see any significant reason to move it out. > > All this would be done by doing a fput(). Also fput() > > would drop a reference on the mount point. So we are doing this then > > we can't call that extra disconnect that was added by another patch. > > nfsd4_interssc_disconnect does not need to access the source file. > I tested both patches together and did not see any problem. If there > is use-after_free condition the code detects it and there would be > warning messages in /var/log/messages. We don't need and don't want to do the nfsd4_interssc_disconnect in the non-error path. All the ref-counting on the superblock is accomplished already. The other patch is not needed and neither is correct, it makes the incorrect refcounts in failure cases. I nack both patches. The only patch which I will send that's needed is this: diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index 8d6d2678abad..3581ce737e85 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -1304,7 +1304,7 @@ nfsd4_cleanup_inter_ssc(struct vfsmount *ss_mnt, struct nfsd_file *src, struct nfsd_file *dst) { nfs42_ssc_close(src->nf_file); - /* 'src' is freed by nfsd4_do_async_copy */ + fput(src->nf_file); nfsd_file_put(dst); mntput(ss_mnt); } > > Anyway I don't see why there is any reason to call anything but the > > fput(), I'm not sure why __nfs42_ssc_close() is a better function and > > doesn't lead to the "use_after_free". > > Since __nfs42_ssc_open was called open the file, I think __nfs42_ssc_close > is an appropriate place to close the file. Again let's keep the cleaning of the server's SSC state in one place. > -Dai > > > > >> static const struct nfs4_ssc_client_ops nfs4_ssc_clnt_ops_tbl = { > >> -- > >> 2.9.5 > >>