Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp306033pxm; Wed, 2 Mar 2022 15:58:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJxp0Qoh3oL9kiNu5bZnQ1tQj2vM9libKw+rU3GWAU0CjpZiPOQ9hMbeNs+nAWfdRyUAx6iU X-Received: by 2002:a65:45c6:0:b0:374:50b4:fc50 with SMTP id m6-20020a6545c6000000b0037450b4fc50mr28384784pgr.443.1646265490609; Wed, 02 Mar 2022 15:58:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646265490; cv=none; d=google.com; s=arc-20160816; b=su8ouUQs8DuSVupK07b4Pc2X7puk7CmwMdQdsnj35Nlth96P5gzlrUh4vopN7RbrM3 FsqKW0Er6EuhOOATXfJjtwFJSvtgdqavch+cphheKuCZ/xL81UwVN4PMnX0YtaJWbkct 2W/FfqvLQ9GqScJfkuvwqiOYTHtD8QQaXJISEL9TQvQ/FrGkZHWkiOOP+CwGR+Vd9GKb v8PR9hyf9LliCX7zEumxpk760ztMOhCHmHS8mSqzwsrrQqic2yOzYwZBNIDqi6Yqn18X fX2aBuG3806bUMW4SSSPKG0ZCEqSOS2L+Bigx+o+uVrcysE5OMnfM0EqAec6h9KbQtGd hkIw== 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:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=GBQVkO6FKMFBJ+tYsMWeTsWw0G/n9BU6P02UAvlYSYc=; b=OZWhOnRuI5fCjWVC8U9NUj79xXTrcg30VTzwdltOjejkNHgriGvuCmS3cV36S/naVG TRe/lzvTCVmsVwppD95eUDSSu6Z4CVcbeYJNnyFWlFiGYVzH7LyRI7hpfxRgSwZ1+OT8 eufk8YqQ0CBOP6n0XTQezemVrFfEeUUF+url/8R7RBw0eGuwi12irWCmoGPEB705+kKS 3dhpiWqyvEyf1pSPrWKH349EvIv1ftJjCmhpw41QehSQ7EOGELUCY7iB8mJa2YDnrsPU w8pbjy+AiwPJsc6G8Ow3fMaEzKSJsqBu26aIKNhN5/ireyUTiaewTEkNcc0xynSEzjas i0Hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=ZgoeB+R4; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=JWKNzmmD; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id e14-20020a63d94e000000b00362b5d4fa96si436453pgj.703.2022.03.02.15.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 15:58:10 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=ZgoeB+R4; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=JWKNzmmD; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 46BF0194AB3; Wed, 2 Mar 2022 15:17:56 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240776AbiCBTfV (ORCPT + 99 others); Wed, 2 Mar 2022 14:35:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241112AbiCBTfU (ORCPT ); Wed, 2 Mar 2022 14:35:20 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D39BFC1C8B; Wed, 2 Mar 2022 11:34:36 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 76FE61F37E; Wed, 2 Mar 2022 19:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1646249675; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GBQVkO6FKMFBJ+tYsMWeTsWw0G/n9BU6P02UAvlYSYc=; b=ZgoeB+R44KO7nrWiiDJRIPHV/BVmVc0gNGBz8+40feaGZQZ1acMs4MWQLJ9jpIdWpDQNdM 4qMFGW3WnLIubPun3AQD6cGkLM559Mp43SAu1w+sIs2+paPjrplOwCLOFWtLAqQd46cmnB NmD30JcgbEzxWR5ewwya6KOTCE44JtI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1646249675; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GBQVkO6FKMFBJ+tYsMWeTsWw0G/n9BU6P02UAvlYSYc=; b=JWKNzmmD5vQhotMi/fHxuFcnThuKpF/J+bAr1Vq6D+cgOkg6jcPvSZ6YAMskFKv9IuMFkt t5fFwmtXag61qHAA== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 135AAA3B84; Wed, 2 Mar 2022 19:34:35 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 08187DA80E; Wed, 2 Mar 2022 20:30:42 +0100 (CET) Date: Wed, 2 Mar 2022 20:30:42 +0100 From: David Sterba To: Niels Dossche Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason , Josef Bacik , David Sterba , Johannes Thumshirn Subject: Re: [PATCH] btrfs: add lockdep_assert_held to need_preemptive_reclaim Message-ID: <20220302193042.GV12643@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Niels Dossche , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason , Josef Bacik , David Sterba , Johannes Thumshirn References: <20220228225215.16552-1-dossche.niels@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220228225215.16552-1-dossche.niels@gmail.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 28, 2022 at 11:52:16PM +0100, Niels Dossche wrote: > In a previous patch I extended the locking for member accesses of > space_info. A reference to another patch would be by a subject or a specific commit id (not applicable in this case) or you can write it without any reference if the change is standalone. The changelog should describe the reason for the change, user visible effects, what can go wrong etc. > It was then suggested to also add a lockdep assertion for > space_info->lock to need_preemptive_reclaim. > > Suggested-by: Johannes Thumshirn > Signed-off-by: Niels Dossche > --- > fs/btrfs/space-info.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c > index 294242c194d8..5464bd168d5b 100644 > --- a/fs/btrfs/space-info.c > +++ b/fs/btrfs/space-info.c > @@ -734,9 +734,13 @@ static bool need_preemptive_reclaim(struct btrfs_fs_info *fs_info, > { > u64 global_rsv_size = fs_info->global_block_rsv.reserved; > u64 ordered, delalloc; > - u64 thresh = div_factor_fine(space_info->total_bytes, 90); > + u64 thresh; > u64 used; > > + lockdep_assert_held(&space_info->lock); > + > + thresh = div_factor_fine(space_info->total_bytes, 90); I'm not sure this is necessary, as this is not locking where the initialization would have to be inside. The lockdep assertion is just a warning, so it does not matter where the intialization is done, I'd prefer to keep it as is.