From patchwork Thu Jun 26 19:12:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4430811 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 54597BEEAA for ; Thu, 26 Jun 2014 19:15:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6AB7E202AE for ; Thu, 26 Jun 2014 19:15:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 941192024D for ; Thu, 26 Jun 2014 19:15:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751840AbaFZTPW (ORCPT ); Thu, 26 Jun 2014 15:15:22 -0400 Received: from mail-qg0-f41.google.com ([209.85.192.41]:64625 "EHLO mail-qg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751658AbaFZTPV (ORCPT ); Thu, 26 Jun 2014 15:15:21 -0400 Received: by mail-qg0-f41.google.com with SMTP id i50so3482906qgf.14 for ; Thu, 26 Jun 2014 12:15:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=+c2keU9dRbjExhCCzvbf+jJWwp0dXHPTQLcYBE4pkP8=; b=NGiypiJjt4kBASTgP59wcEv3qsJ6FyOp4k4cO5PyCWK/LcaNML0l4lIQhvBmfAV4q3 T8wpWNpwxnkVbH69zROzLB8ioNnDrYS6GK5FJySQBbMiT9OyG9Mbz/RN3DYSeqw/iQE5 VlY4wbkaa5/ZAkIboTWT10PEJxt5x7EDFZ4szaW1Q8pyFU+urNNnZKdS7qvRzu6vlsB+ Ka1CfqBHKSbndRPk1pRHqs9u+AeWGWPP4HLx3BizqEe/WDiKpRV8zcPHoJ3122hwYwff QbNtQA4s0m499VJftUhx3Q7tQs4tbg5RWCQTPzHfDgong5a6g3FnE89vYmmCxSc7UfF5 AN6A== X-Gm-Message-State: ALoCoQnGt7LvPoMr1e11XshFozTb0KEqAIwjamN6bS6GFHnOqWx6/ExoD/DchRmLn6NmtNxjrZm8 X-Received: by 10.224.165.70 with SMTP id h6mr25710878qay.78.1403810120767; Thu, 26 Jun 2014 12:15:20 -0700 (PDT) Received: from tlielax.poochiereds.net ([2001:470:8:d63:3a60:77ff:fe93:a95d]) by mx.google.com with ESMTPSA id 88sm4763039qgh.5.2014.06.26.12.15.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jun 2014 12:15:20 -0700 (PDT) From: Jeff Layton To: bfields@fieldses.org Cc: linux-nfs@vger.kernel.org Subject: [PATCH v2 070/117] nfsd: don't allow CLOSE to proceed until refcount on stateid drops Date: Thu, 26 Jun 2014 15:12:50 -0400 Message-Id: <1403810017-16062-71-git-send-email-jlayton@primarydata.com> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1403810017-16062-1-git-send-email-jlayton@primarydata.com> References: <1403810017-16062-1-git-send-email-jlayton@primarydata.com> Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Once we remove client_mutex protection, it'll be possible to have an in-flight operation using an openstateid when a CLOSE call comes in. If that happens, we can't just put the sc_file reference and clear its pointer without risking an oops. Fix this by ensuring that v4.0 CLOSE operations wait for the refcount to drop before proceeding to do so. Signed-off-by: Jeff Layton --- fs/nfsd/nfs4state.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index d1b55d61ae6f..029e41b4de84 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -89,6 +89,12 @@ static DEFINE_MUTEX(client_mutex); */ static DEFINE_SPINLOCK(state_lock); +/* + * A waitqueue for all in-progress 4.0 CLOSE operations that are waiting for + * the refcount on the open stateid to drop. + */ +static DECLARE_WAIT_QUEUE_HEAD(close_wq); + static struct kmem_cache *openowner_slab; static struct kmem_cache *lockowner_slab; static struct kmem_cache *file_slab; @@ -670,8 +676,10 @@ static void nfs4_put_stid(struct nfs4_stid *s) { struct nfs4_client *clp = s->sc_client; - if (!atomic_dec_and_lock(&s->sc_count, &clp->cl_lock)) + if (!atomic_dec_and_lock(&s->sc_count, &clp->cl_lock)) { + wake_up_all(&close_wq); return; + } remove_stid_locked(clp, s); spin_unlock(&clp->cl_lock); s->sc_free(s); @@ -3073,11 +3081,23 @@ move_to_close_lru(struct nfs4_ol_stateid *s, struct net *net) dprintk("NFSD: move_to_close_lru nfs4_openowner %p\n", oo); + /* + * We know that we hold one reference via nfsd4_close, and another + * "persistent" reference for the client. If the refcount is higher + * than 2, then there are still calls in progress that are using this + * stateid. We can't put the sc_file reference until they are finished. + * Wait for the refcount to drop to 2. Since it has been unhashed, + * there should be no danger of the refcount going back up again at + * this point. + */ + wait_event(close_wq, atomic_read(&s->st_stid.sc_count) == 2); + release_all_access(s); if (s->st_stid.sc_file) { put_nfs4_file(s->st_stid.sc_file); s->st_stid.sc_file = NULL; } + release_last_closed_stateid(oo); oo->oo_last_closed_stid = s; list_move_tail(&oo->oo_close_lru, &nn->close_lru);