From patchwork Thu Jul 14 15:28:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 12918111 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C941C43334 for ; Thu, 14 Jul 2022 15:28:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239872AbiGNP2Z (ORCPT ); Thu, 14 Jul 2022 11:28:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240163AbiGNP2Z (ORCPT ); Thu, 14 Jul 2022 11:28:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 707094A806 for ; Thu, 14 Jul 2022 08:28:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 20B60B823EF for ; Thu, 14 Jul 2022 15:28:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52115C34114; Thu, 14 Jul 2022 15:28:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657812501; bh=bFjxaIUTnnDoW4zI+ASN9c+4WEQq2zjy4uxzo3aN4dc=; h=From:To:Cc:Subject:Date:From; b=Zve+pIV7+Vx4zw58K/x0VRWB7eFjz481VXYG5mHi8SaKdoORJuPDz8IKzuD1f1dT9 mLNga9+2mhE6f0bGMBJBAU3zEAscMeyCYaBnpPyw03CS2CNCDowKy+DGJfCzvdpaz1 OaW+NU30WU5Foi+YQHaVKDVnirnBXR8Lsqkpg6yYsHd9X02YwJup2RI3pfJxKaHKog xeone5FJ21nWk6/TBvYW8QW+gwAAzDXwxq/zxVbgNdEukKReRZ/T5kaFYF7TADg1dU UQI26PMUIy4lpWNpBkPgJBfgv92IVqEwp137TwgeYUNT0u850EnNVBjUk9VrQT8+VW dT6pzvZpIhD5A== From: Jeff Layton To: chuck.lever@oracle.com Cc: neilb@suse.de, linux-nfs@vger.kernel.org Subject: [RFC PATCH 0/3] nfsd: close potential race between open and setting delegation Date: Thu, 14 Jul 2022 11:28:16 -0400 Message-Id: <20220714152819.128276-1-jlayton@kernel.org> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Here's a first stab at a patchset to close a potential race when setting a delegation on a file. Between the point where we open the file and where we set the delegation, another task or client could unlink or rename the dentry. If that occurs, we shouldn't hand out a delegation in the open response, but we don't prevent that today. The basic idea here is to re-do the lookup after setting the delegation. If the resulting dentry is not the one we have in the open, then we can reject handing out a delegation. Only lightly tested, so this is an RFC for now. Jeff Layton (3): nfsd: drop fh argument from alloc_init_deleg nfsd: rework arguments to nfs4_set_delegation nfsd: vet the opened dentry after setting a delegation fs/nfsd/nfs4state.c | 65 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 55 insertions(+), 10 deletions(-)