Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp2004808rwn; Fri, 9 Sep 2022 07:17:12 -0700 (PDT) X-Google-Smtp-Source: AA6agR4Ph5f/1LxIbGe6L8cL3s5SKB84I8RrZm+t+Wz7+6DmhbUNMiKcUaDxe9vYydc0cfV2w0qh X-Received: by 2002:a2e:9e43:0:b0:25d:d8e9:7b15 with SMTP id g3-20020a2e9e43000000b0025dd8e97b15mr4070103ljk.234.1662733032337; Fri, 09 Sep 2022 07:17:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662733032; cv=none; d=google.com; s=arc-20160816; b=zdh1+WjGB2KChhNjM819BnnMD7qLFeOk/Mlqmz5dAL1IFrz3EHfTAsrQVCer5KR8F8 M9fDQgwRgQccrsQosUHtNT1HwOZMsiM/7+D6SBXxEehhcUK5ox0Emm/6uB+s9NULL2Vg d07+w14PGrtnhxOQVxogg4XLkWa6bi5xNNuI5VbSuLvpy1FZAGrtGGnYcItGkAlhDVNa fUWo+fZZXrt4Wxf+H8rhcUdNLuRNoRSFPFQr0rjX3OvoToJUC7GCQgKmPvIeeAF1Ygi4 uehBV7TGsSUtV/9wbtXZRMPep6+s9N+ytBRKN9sycYLTjkWsZUYcY3gwRVcdfydKiqnV TSLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=ZAvy1zrYwy9XTqh4ODG8ma1JhILysPikvRzldVe3EIw=; b=SnTKrbYSil0OlzoiGzdGHvXHBjVeH2vQMIvpuZsUPtSZ+Yq9t/taIvsAweB8VW2ibS Y47D6L6H4QfoRBiTA0D0w1tKiUXxN5fr8Pg9Txq4TGpFYcB8388DoOL0OOAP64g4XyeV pb3Ne7im8ARgOqF/2Cc+ptcixpeq4w4Pt7kyCfKxLxxCIx22g7sqJhksB3oFDgD9c2h0 vBGqgCwwT6lod3MX4nAn8AMXS8D1awmR6SlCBEQFUYIaYwZwlTz4zSWRQK/QFtkHkuLN OJzCc+gGqOmbi6W4t6fiG0vfDfkxlHNN0dqvfpx+mHRqTVY0BEJFCYCTudElaTCPt/wt 02BQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=yj53lHF4; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z26-20020a2e351a000000b00269560eee5esi246948ljz.472.2022.09.09.07.16.40; Fri, 09 Sep 2022 07:17:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=yj53lHF4; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232245AbiIIOBy (ORCPT + 99 others); Fri, 9 Sep 2022 10:01:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232078AbiIIOAt (ORCPT ); Fri, 9 Sep 2022 10:00:49 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B30997F13B; Fri, 9 Sep 2022 07:00:32 -0700 (PDT) Date: Fri, 09 Sep 2022 14:00:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1662732031; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZAvy1zrYwy9XTqh4ODG8ma1JhILysPikvRzldVe3EIw=; b=yj53lHF4ifqca4ewyc7V72N9qYpXrk7wGlYVr5ACnQRpE7imjnLV7rNiwPQzyZzsnfDNsl CDa5+dVaflJnmCWGUnoYYgzzdOqINPzmkkJ/XRT8UcS6Wlxc0ExJq5QtQNYAINsSI7+Xwc 2peo9VP6ubXLheppAJejyKwvU/CgwRhXE7eBeN3gL5M8zj6D2kzIy+A9hPMeRzXDaj1y4o 0i4/vfOVdJHZbCj/eq6gZ8is3FxG/9VMPTaiuo1FljblVl7GfeZnnGARVGbexbOnM9WpMU ivDSpX4LiyU3NORs9XDB9vyxyRKuUoW+4ZyGLJT4x/IuSY6C4kb/zlUqba03PQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1662732031; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZAvy1zrYwy9XTqh4ODG8ma1JhILysPikvRzldVe3EIw=; b=FWmgdlcyvjfvFjzRj2ePr1x0lQgBIPvX2AaVAY82sXG1WB28XP7eQvlZs9oWaFvEBi0qEi n9cPA9S9zFBnLdAA== From: "tip-bot2 for Tejun Heo" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/psi] kernfs: Improve kernfs_drain() and always call on removal Cc: Chengming Zhou , Tejun Heo , "Greg Kroah-Hartman" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20220828050440.734579-6-tj@kernel.org> References: <20220828050440.734579-6-tj@kernel.org> MIME-Version: 1.0 Message-ID: <166273202980.401.2949316254189258021.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 The following commit has been merged into the sched/psi branch of tip: Commit-ID: 2d7f9f8c1815707e9ddb454648a523efc67a04d3 Gitweb: https://git.kernel.org/tip/2d7f9f8c1815707e9ddb454648a523efc67a04d3 Author: Tejun Heo AuthorDate: Sat, 27 Aug 2022 19:04:36 -10:00 Committer: Greg Kroah-Hartman CommitterDate: Thu, 01 Sep 2022 18:08:44 +02:00 kernfs: Improve kernfs_drain() and always call on removal __kernfs_remove() was skipping draining based on KERNFS_ACTIVATED - whether the node has ever been activated since creation. Instead, update it to always call kernfs_drain() which now drains or skips based on the precise drain conditions. This ensures that the nodes will be deactivated and drained regardless of their states. This doesn't make meaningful difference now but will enable deactivating and draining nodes dynamically by making removals safe when racing those operations. While at it, drop / update comments. v2: Fix the inverted test on kernfs_should_drain_open_files() noted by Chengming. This was fixed by the next unrelated patch in the previous posting. Cc: Chengming Zhou Tested-by: Chengming Zhou Reviewed-by: Chengming Zhou Signed-off-by: Tejun Heo Link: https://lore.kernel.org/r/20220828050440.734579-6-tj@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/kernfs/dir.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c index 8ae44db..b3d2018 100644 --- a/fs/kernfs/dir.c +++ b/fs/kernfs/dir.c @@ -472,6 +472,16 @@ static void kernfs_drain(struct kernfs_node *kn) lockdep_assert_held_write(&root->kernfs_rwsem); WARN_ON_ONCE(kernfs_active(kn)); + /* + * Skip draining if already fully drained. This avoids draining and its + * lockdep annotations for nodes which have never been activated + * allowing embedding kernfs_remove() in create error paths without + * worrying about draining. + */ + if (atomic_read(&kn->active) == KN_DEACTIVATED_BIAS && + !kernfs_should_drain_open_files(kn)) + return; + up_write(&root->kernfs_rwsem); if (kernfs_lockdep(kn)) { @@ -480,7 +490,6 @@ static void kernfs_drain(struct kernfs_node *kn) lock_contended(&kn->dep_map, _RET_IP_); } - /* but everyone should wait for draining */ wait_event(root->deactivate_waitq, atomic_read(&kn->active) == KN_DEACTIVATED_BIAS); @@ -1370,23 +1379,14 @@ static void __kernfs_remove(struct kernfs_node *kn) pos = kernfs_leftmost_descendant(kn); /* - * kernfs_drain() drops kernfs_rwsem temporarily and @pos's + * kernfs_drain() may drop kernfs_rwsem temporarily and @pos's * base ref could have been put by someone else by the time * the function returns. Make sure it doesn't go away * underneath us. */ kernfs_get(pos); - /* - * Drain iff @kn was activated. This avoids draining and - * its lockdep annotations for nodes which have never been - * activated and allows embedding kernfs_remove() in create - * error paths without worrying about draining. - */ - if (kn->flags & KERNFS_ACTIVATED) - kernfs_drain(pos); - else - WARN_ON_ONCE(atomic_read(&kn->active) != KN_DEACTIVATED_BIAS); + kernfs_drain(pos); /* * kernfs_unlink_sibling() succeeds once per node. Use it