From patchwork Wed Jan 21 22:29:39 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Olga Kornievskaia X-Patchwork-Id: 5680701 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 693B4C058D for ; Wed, 21 Jan 2015 22:29:45 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 79F1C20480 for ; Wed, 21 Jan 2015 22:29:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A01020497 for ; Wed, 21 Jan 2015 22:29:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752337AbbAUW3m (ORCPT ); Wed, 21 Jan 2015 17:29:42 -0500 Received: from mail-la0-f42.google.com ([209.85.215.42]:38642 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752086AbbAUW3l convert rfc822-to-8bit (ORCPT ); Wed, 21 Jan 2015 17:29:41 -0500 Received: by mail-la0-f42.google.com with SMTP id ms9so20693547lab.1 for ; Wed, 21 Jan 2015 14:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NFTjIpmwSkXEHza+AzZZj/E5tKo1e4xYCt/l5HCIG/U=; b=ZttUupnn81AedPf66ugOpHWZ6Zrl4OLHjox+hK7C9iElz/sKFbM91OoE7bSXdH1U6n vp1ofzgn9Gctbetu12/uFfF1OFJQjkrgY99fyi3SXoH611eSZT2q13wtdt3PdE3dBXu1 6o21hVfBgSX2vveKtP5mxNhZ3mkkhoYuvxRSqUde1XzDFOUfOhC3sQBoI01V1wk6Y3VE +Cp7VzXaV7txSV50TAFpPYpmbv4bdac95Pn937VeEYWiLZEgcp3fcUVvyfftXGyeLLu1 4Qv8ofnPPrcaw0alRqR4ibyGWpuI12LCNdJ9a/T+5ax323wsUa5RHIPbN/hS5e7MS7ks ZD6w== MIME-Version: 1.0 X-Received: by 10.112.61.228 with SMTP id t4mr5900193lbr.0.1421879379974; Wed, 21 Jan 2015 14:29:39 -0800 (PST) Received: by 10.25.31.9 with HTTP; Wed, 21 Jan 2015 14:29:39 -0800 (PST) Date: Wed, 21 Jan 2015 17:29:39 -0500 X-Google-Sender-Auth: f6B6KoYdtFqxCWhDKofksNK7qn8 Message-ID: Subject: race between inode eviction with delegation and opening same file From: Olga Kornievskaia To: Trond Myklebust Cc: linux-nfs 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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,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 There is a race between return of a delegation (due to resource constraints and inode getting evicted) and an open for the same file because…. In nfs_inode_return_delegation_noreclaim() we detach that delegation from the inode first (nfs_inode_detach_delegation()) and then we send a delegreturn. In between of nfs_inode_detach_delegation() and nfs_do_return_delegation() an open request comes and it doesn’t see any delegations for this inode and thus it sends an open request. At the same time eviction thread is working on doing a delegreturn for this inode. The server gets request for the open first and returns a delegation for it (note: server will issue the same delegation stateid but different seqnum as the one currently being returned by the client). Then the server processes a delegreturn for this file (from its perspective delegation stateid is no longer valid). Yet, on the client side as it processes a reply from the server, it adds a “new” delegation to the inode and proceeds to use it for an IO request later which errors in BAD_STATEID. I don't see how we can make detaching the delegation and the return of it atomic. Instead I propose the following solution: I propose to examine the delegation we get on open. If the sequence number is not 0 and we don't have a delegation already then we must have experienced this race. Therefore, we should return the delegation (and ignore if this errors, as the server thinks there is no more delegation). Something like this. Disclaimer: it doesn't seem to be the actual fix (as it hangs the machine) so I'm still missing something .... --- 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/nfs/delegation.c b/fs/nfs/delegation.c index b76166b..01bba63 100644 --- a/fs/nfs/delegation.c +++ b/fs/nfs/delegation.c @@ -368,5 +368,12 @@ int nfs_inode_set_delegation(struct inode *inode, struct rpc_cred *cred, struct old_delegation, clp); if (freeme == NULL) goto out; + } else { + if (be32_to_cpu(delegation->stateid.seqid) > 0) { + nfs_do_return_delegation(inode, delegation, 0); + goto out; + } } list_add_rcu(&delegation->super_list, &server->delegations); nfsi->delegation_state = delegation->type;