From patchwork Fri May 15 15:52:08 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Olga Kornievskaia X-Patchwork-Id: 6415321 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 8E4AFC0432 for ; Fri, 15 May 2015 15:52:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 809EA20204 for ; Fri, 15 May 2015 15:52:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CDB9F201C0 for ; Fri, 15 May 2015 15:52:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934758AbbEOPwK (ORCPT ); Fri, 15 May 2015 11:52:10 -0400 Received: from mail-ig0-f179.google.com ([209.85.213.179]:38272 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934744AbbEOPwJ convert rfc822-to-8bit (ORCPT ); Fri, 15 May 2015 11:52:09 -0400 Received: by igcau1 with SMTP id au1so31590078igc.1 for ; Fri, 15 May 2015 08:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Qx0GStm/qE8YIhIVRTqb+kpcu8ZQ0habFzQRXN3mkaY=; b=ocVOxaCmiV4PhezJIZHwCM3PKrgBT1QgjNuwpJq7tHLBix3wdSZU508JLaHztIBfV9 PSmsKNpiYAJQFqsC571j0szn4L5mInYB0/2V0XthCKmXBT5Es+LeTtsYiuh3mwo9cp2k feMnkqy14+686CkiSk+InPjC9AaRkRTTem6qymOPKxxrAAf5cJfYnN7xHh0v/WM2rcK8 V/R95rfoRk5nhaWYs+j8vDe57AN0YqnDCoAco04P6ffSExZOTfrlyfvQ4eZm5NBfgnas vK6sSnlXUWkHJmMyB3LoaOdlTsKUUpBiEKliPhFU//1inC9kO7881lPGw1IUP0pLqZ/P tccA== MIME-Version: 1.0 X-Received: by 10.107.8.87 with SMTP id 84mr10259394ioi.87.1431705128615; Fri, 15 May 2015 08:52:08 -0700 (PDT) Received: by 10.107.184.9 with HTTP; Fri, 15 May 2015 08:52:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 May 2015 11:52:08 -0400 X-Google-Sender-Auth: xzq0HhrsUb4hQp35d1Lmuy3YqL0 Message-ID: Subject: Re: 4.0 NFS client in infinite loop in state recovery after getting BAD_STATEID From: Olga Kornievskaia To: Trond Myklebust , 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 Here's another version: Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it marks the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by: Olga Kornievskaia --- fs/nfs/nfs4state.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index 2782cfc..e99e1f0 100644 --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1482,6 +1482,8 @@ restart: spin_unlock(&state->state_lock); } nfs4_put_open_state(state); + test_and_clear_bit(NFS4CLNT_RECLAIM_NOGRACE, + &state->flags); spin_lock(&sp->so_lock); goto restart; }