Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp642513pxb; Tue, 3 Nov 2020 08:42:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwbcC7Xq64daKC9vReECt7Jq8Z9rqGJjgyQk0NbhcaHUOHu3U4YsNGjoKDCa76AETC9SndA X-Received: by 2002:a05:6402:a53:: with SMTP id bt19mr12173463edb.26.1604421754599; Tue, 03 Nov 2020 08:42:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604421754; cv=none; d=google.com; s=arc-20160816; b=QWkRF1CJMxEqU7ObtEiRGFGD/jtROak2k/8hZWo6GdCLWAq4eWvTK/1ZHZiiwLZIi7 5N3h42x8FInCEFhSsftC58zj5EQt7fBcHoskXL/eOgJTzFcLT++8pXoFOKr+N7J3U7VI NLGxFvaL2u941PUx34gjSvlUDm7SWtGDaHu2ZOXuzHr5SlR5jysIOdPMJKxTqE2nQtKc X0auQgRVlMNrJWFIXxdbMmgen99xiCVY82qVolxmESHRzvyaqplXJJCdSU8Zex3+cczj FsNsc9hSmei6tQGacCJNRrK4GLCF24B5TtST0X9XOyLugSjs8zrosAAetIsG5Cg6bgMq /S5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=XpVPKtU0u9+vJmZ9Cix4LdkoJm4IiI/Zp2I20Y/OhP8=; b=RRRrKt+yEzJGqZf2VvUsC2AEzO5/9r+108U7dbFIX0OLCaNuUGNW8odDpKXVlqaxtk Jr6aeKmuXqj7VUF6Y3IFBk37OvpJwkxaZQsah3hQXWv6QgrlzR6PXLrAVLApxi7u4v9a YFk/yxAx4VZDspczvuAdjkvD50uFYStqBSfyJpqLdlmceqyLeKJsvELV8vQnRf9VrnGF EyN8WIVhvMTFuDRLltNMuKQgREsuP1IvrTIpkvhUfNakR7uvaIG2B4ca1QUFfUrQh0qN iPaP4C5wdtHuuOYbY23I5eo8cFKqaky1XVOB0Atgqns56pPpCavCI8bzOh+24jwOwtQr IkRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a23si14081296edn.292.2020.11.03.08.42.11; Tue, 03 Nov 2020 08:42:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727470AbgKCQmF (ORCPT + 99 others); Tue, 3 Nov 2020 11:42:05 -0500 Received: from mx2.suse.de ([195.135.220.15]:55172 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgKCQmF (ORCPT ); Tue, 3 Nov 2020 11:42:05 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 30D7FB240; Tue, 3 Nov 2020 16:42:04 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 9E6B51E12FB; Tue, 3 Nov 2020 17:42:03 +0100 (CET) Date: Tue, 3 Nov 2020 17:42:03 +0100 From: Jan Kara To: Harshad Shirwadkar Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, jack@suse.cz Subject: Re: [PATCH 06/10] ext4: dedpulicate the code to wait on inode that's being committed Message-ID: <20201103164203.GJ3440@quack2.suse.cz> References: <20201031200518.4178786-1-harshadshirwadkar@gmail.com> <20201031200518.4178786-7-harshadshirwadkar@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201031200518.4178786-7-harshadshirwadkar@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sat 31-10-20 13:05:14, Harshad Shirwadkar wrote: > This patch removes the deduplicates the code that implements waiting > on inode that's being committed. That code is moved into a new > function. > > Suggested-by: Jan Kara > Signed-off-by: Harshad Shirwadkar Looks good to me. Just one nit below: > diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c > index b1ca55c7d32a..0f2543220d1d 100644 > --- a/fs/ext4/fast_commit.c > +++ b/fs/ext4/fast_commit.c > @@ -155,6 +155,28 @@ void ext4_fc_init_inode(struct inode *inode) > ei->i_fc_committed_subtid = 0; > } > > +static void ext4_fc_wait_committing_inode(struct inode *inode) > +{ > + wait_queue_head_t *wq; > + struct ext4_inode_info *ei = EXT4_I(inode); > + Maybe add lockdep_assert_held(&EXT4_SB(inode->i_sb)->s_fc_lock) here to make sure the function is called properly? It's kind of unobvious requirement (but hard to avoid)... > +#if (BITS_PER_LONG < 64) > + DEFINE_WAIT_BIT(wait, &ei->i_state_flags, > + EXT4_STATE_FC_COMMITTING); > + wq = bit_waitqueue(&ei->i_state_flags, > + EXT4_STATE_FC_COMMITTING); > +#else > + DEFINE_WAIT_BIT(wait, &ei->i_flags, > + EXT4_STATE_FC_COMMITTING); > + wq = bit_waitqueue(&ei->i_flags, > + EXT4_STATE_FC_COMMITTING); > +#endif > + prepare_to_wait(wq, &wait.wq_entry, TASK_UNINTERRUPTIBLE); > + spin_unlock(&EXT4_SB(inode->i_sb)->s_fc_lock); > + schedule(); > + finish_wait(wq, &wait.wq_entry); > +} > + Honza -- Jan Kara SUSE Labs, CR