From patchwork Wed Jul 30 01:34:33 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4644231 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id DE11D9F36A for ; Wed, 30 Jul 2014 01:35:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1DE9020145 for ; Wed, 30 Jul 2014 01:35:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4D0B420142 for ; Wed, 30 Jul 2014 01:35:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754745AbaG3Bff (ORCPT ); Tue, 29 Jul 2014 21:35:35 -0400 Received: from mail-qa0-f51.google.com ([209.85.216.51]:63499 "EHLO mail-qa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754725AbaG3Bfd (ORCPT ); Tue, 29 Jul 2014 21:35:33 -0400 Received: by mail-qa0-f51.google.com with SMTP id k15so611053qaq.10 for ; Tue, 29 Jul 2014 18:35:32 -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=gVmP7rcN8Cy0KHC59FzB1Gfrt3MAY/4EpFt/Kzqr5n0=; b=MSVRImaZOVSko9kD9+NNVWUbgDZ4kf6aDmS64X80RTRE4nvfbsydwg9bAF/r3rV3E4 0uvJNrvOaLlUGF29Go7BpvchFjXebToTBCxTwjoFjgcn+o2w09JCfo6LEBgUcksZ4LBP KoUd09VCe6yFTQwk2oFYQfDsjEzXZWdnIHiOs7jOsoXUdymDb3/BeGTE9tHVUCruQ8da 20EeUYxpKsNkJmpNm4VGEJjAWIHgBNwqvvE8znDB5cEE/ucDy7WFcG8B0XYbGw7pqf8H SrBKUoV8fPoysLWAJ4Ie4H4fu8B8atGE91i63phgxn4sYD9wviNteA8w/v4pT45apqNq HWhg== X-Gm-Message-State: ALoCoQmbynFTbaPgrv6O/rJcisAr7gWe7srjqVXcW6eyhA1ShUQsiQaHjfxVBRtJB2GyWxMZsIWo X-Received: by 10.140.22.69 with SMTP id 63mr1121760qgm.23.1406684132324; Tue, 29 Jul 2014 18:35:32 -0700 (PDT) Received: from tlielax.poochiereds.net ([2001:470:8:d63:3a60:77ff:fe93:a95d]) by mx.google.com with ESMTPSA id 81sm860946qgw.21.2014.07.29.18.35.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jul 2014 18:35:31 -0700 (PDT) From: Jeff Layton To: bfields@fieldses.org Cc: linux-nfs@vger.kernel.org, hch@infradead.org Subject: [PATCH v3 28/38] nfsd: don't allow CLOSE to proceed until refcount on stateid drops Date: Tue, 29 Jul 2014 21:34:33 -0400 Message-Id: <1406684083-19736-29-git-send-email-jlayton@primarydata.com> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1406684083-19736-1-git-send-email-jlayton@primarydata.com> References: <1406684083-19736-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=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, 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 | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index b61319401826..6d26d26751f5 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -85,6 +85,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; @@ -640,8 +646,10 @@ nfs4_put_stid(struct nfs4_stid *s) might_lock(&clp->cl_lock); - 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; + } idr_remove(&clp->cl_stateids, s->sc_stateid.si_opaque.so_id); spin_unlock(&clp->cl_lock); s->sc_free(s); @@ -3070,6 +3078,17 @@ 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);