From patchwork Sat Aug 6 02:26:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 9266139 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 88AC460754 for ; Sat, 6 Aug 2016 23:34:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6C7EA283DF for ; Sat, 6 Aug 2016 23:34:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 612752841F; Sat, 6 Aug 2016 23:34:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CAFDB283DF for ; Sat, 6 Aug 2016 23:34:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751110AbcHFXeZ (ORCPT ); Sat, 6 Aug 2016 19:34:25 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:34459 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751042AbcHFXeY (ORCPT ); Sat, 6 Aug 2016 19:34:24 -0400 Received: by mail-io0-f196.google.com with SMTP id i199so4357989ioi.1 for ; Sat, 06 Aug 2016 16:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:from:to:date:message-id:user-agent:mime-version :content-transfer-encoding; bh=MhJJEsvLQHBakfzAxRKMyRWlcJGnKD0AO3W/t5E98lo=; b=LNWAHnU2p1SUOtJ4qeWejrboUy7Ch9KOuylsXIW9pwzY7950ryQkqwN8+3iAfoFfrD l+/Eke8GLt7AGLlxAGmNToxpWHD5ejxMHsLFVwf4Z7Qfr4WH6Q6e2f2oCRA0DUGQClpE qR4lQQBT1pMVtSSFpB7Zi8H/rInVjrQXH8xE2zWGTlAHQgbkwHKKvsDbLYz/HNibuZ6A Gw6ixdVr5kmZycw3l1olQY/7mBevJ2BnkDgwltWukQDcjngdz/DNMvnN4pni7NqG78s5 Mi1/Q7LECeVzN4XeinlArdw8rvkjo/ZXw9hbFaXZ3v5sldJgdn79VxZokHWYMSEEwWnQ cixA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:from:to:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=MhJJEsvLQHBakfzAxRKMyRWlcJGnKD0AO3W/t5E98lo=; b=kwPNtQOCSga7WxRH22jCYJHHYGcEJhUgxr2GLJJ5JlKZ13N4WuIzN+vio9GvlqNk6l IBbwanTrsBfcRwLWpimyPuyHaHzou/np1EPVXyxg/Lh31yzGjl2SSC1EueJG9NLB2zim B6JBQCdq+aaLHAClPP0heRhjjvbzQmqlrWwVxoIS0RyYXU48+uLHdYNPtbHN2fy1ssBf XIKgqBJUp2R0kd1bFYxQVZ4yaVBeqZULtkb9f/T+W44kTgRUnCXPb9a6Wu9TtN28XV8Y CJ6Xv258Zd3JpUxEDZWZhVFpEP4vtWURO7BTpoJH20xwgPhT3E4OEUrmtpdXY3PewR2r NQ8w== X-Gm-Message-State: AEkooutetsXTbr1z+APWf1NDQvXTzn2Me4joauaZqVY+3Ucz0thVqIMQyNce19Ts3HwQOw== X-Received: by 10.107.145.214 with SMTP id t205mr79437047iod.135.1470450396809; Fri, 05 Aug 2016 19:26:36 -0700 (PDT) Received: from klimt.1015granger.net ([2604:8800:100:81fc:ec4:7aff:fe6c:6aa0]) by smtp.gmail.com with ESMTPSA id h63sm5125763ita.12.2016.08.05.19.26.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 19:26:36 -0700 (PDT) Subject: [PATCH v1] nfsd: Fix race between FREE_STATEID and LOCK From: Chuck Lever To: linux-nfs@vger.kernel.org Date: Fri, 05 Aug 2016 22:26:35 -0400 Message-ID: <20160806022349.3381.8042.stgit@klimt.1015granger.net> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Using LTP's nfslock01 test, one of our internal testers found that the Linux client can send a LOCK and a FREE_STATEID request at the same time. The LOCK uses the same lockowner as the stateid sent in the FREE_STATEID request. The outcome is: Frame 115025 C FREE_STATEID stateid 2/A Frame 115026 C LOCK offset 672128 len 64 Frame 115029 R FREE_STATEID NFS4_OK Frame 115030 R LOCK stateid 3/A Frame 115034 C WRITE stateid 0/A offset 672128 len 64 Frame 115038 R WRITE NFS4ERR_BAD_STATEID In other words, the server returns stateid A in the LOCK reply, but it has already released it. Subsequent uses of the stateid fail. To address this, protect the logic in nfsd4_free_stateid with the st_mutex. This should guarantee that only one of two outcomes occurs: either LOCK returns a fresh valid stateid, or FREE_STATEID returns NFS4ERR_LOCKS_HELD. Reported-by: Alexey Kodanev Fix-suggested-by: Jeff Layton Signed-off-by: Chuck Lever --- Before I pass this along to Alexey for testing, I'd appreciate some review of the proposed fix. fs/nfsd/nfs4state.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index b921123..a9e0606 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -4911,16 +4911,24 @@ nfsd4_free_stateid(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, ret = nfserr_locks_held; break; case NFS4_LOCK_STID: - ret = check_stateid_generation(stateid, &s->sc_stateid, 1); - if (ret) - break; + spin_unlock(&cl->cl_lock); stp = openlockstateid(s); + mutex_lock(&stp->st_mutex); + ret = check_stateid_generation(stateid, &s->sc_stateid, 1); + if (ret) { + mutex_unlock(&stp->st_mutex); + goto out; + } ret = nfserr_locks_held; if (check_for_locks(stp->st_stid.sc_file, - lockowner(stp->st_stateowner))) - break; + lockowner(stp->st_stateowner))) { + mutex_unlock(&stp->st_mutex); + goto out; + } + spin_lock(&cl->cl_lock); WARN_ON(!unhash_lock_stateid(stp)); spin_unlock(&cl->cl_lock); + mutex_unlock(&stp->st_mutex); nfs4_put_stid(s); ret = nfs_ok; goto out;