From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22C8DCA0EF2 for ; Tue, 12 Sep 2023 15:27:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B12586B0111; Tue, 12 Sep 2023 11:27:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC1296B0112; Tue, 12 Sep 2023 11:27:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 988DC6B0113; Tue, 12 Sep 2023 11:27:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 82DCE6B0111 for ; Tue, 12 Sep 2023 11:27:19 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5428E16024F for ; Tue, 12 Sep 2023 15:27:19 +0000 (UTC) X-FDA: 81228324198.20.66D1570 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 9C9521C001F for ; Tue, 12 Sep 2023 15:27:17 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JxLTLAoC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694532437; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J8XzqjbQG2w7akY6jbm7b50IL0pbgPuHElso6LXmHxM=; b=oylhW6iAVu9yzThH+bbjIV5fd3QrAtos6NwcCSjS7qU5Mh90B0bhMuSzSOck9XARZ0rS/L 5/l2TDeoM6CeCUBF6qSr7b0yiSuOab5gkWeduCWC3AjlzXYrsGfrZYw/32H3SFJ026aeIn 2xJyYaTHmoaF2OVbTlvji/RaeJpGY+U= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JxLTLAoC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694532437; a=rsa-sha256; cv=none; b=ymJvrTsfgVc8QKBB9LaRhFaWe2NK5m2IoBLXBRQtDCUJFjN0pc9JyAQEcR/QFiYL21FEcy o/2EfgJbZ8AOXYSpT4/5HXCwuukUBIxfiGcmKAixSQ9IYYif/lMABm1hwKrGTSr20qlZHi ef96lSKEKA/p84znGRN+e82Li13Zycc= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AAE5561259; Tue, 12 Sep 2023 15:27:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E0A0C433C8; Tue, 12 Sep 2023 15:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694532436; bh=zT75Ab5rlByJQL3D5lDMEHE8CDUMBia7LGb43n9vDS4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JxLTLAoCSRdKjo6pL+3MS5DEaBWsenCUs0N8SkssjHARH/CqFQEPOYzXQGjoXdE/c gld3jHG2xwr+gXWQdKrakUrMSSmclIDeErK6gBLn/ajuOfYbLShdEdOkL+lJ50pJ5l T3/os9dNfX1VZ0c+6oebRd5nuwD06sfPSMDaHa/m6q3Vc+hiPyOMI2pH2I5DaLWeUu ntiamSBnRmk5cgXF0A/Ofm8uQcoXZFXAliTPTlBt/jXBC8tp7MHOcWX9R3Ydig3gN2 yAHJy+xkZTJtNq8X+quCVIqw7lR9lvQqHjAMpg/6wpwrzRK2JzYqp8ng5PQpLAefi/ Oh8uXPlpH21CQ== Date: Tue, 12 Sep 2023 08:27:15 -0700 From: "Darrick J. Wong" To: Peter Zijlstra Cc: Matthew Wilcox , Dave Chinner , Waiman Long , Ingo Molnar , Will Deacon , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chandan Babu R , linux-xfs@vger.kernel.org Subject: Re: [PATCH 1/5] locking: Add rwsem_is_write_locked() Message-ID: <20230912152715.GS28202@frogsfrogsfrogs> References: <70d89bf4-708b-f131-f90e-5250b6804d48@redhat.com> <20230912090342.GC35261@noisy.programming.kicks-ass.net> <20230912135213.GA22127@noisy.programming.kicks-ass.net> <20230912142300.GC22127@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230912142300.GC22127@noisy.programming.kicks-ass.net> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9C9521C001F X-Stat-Signature: wcaaz1easfrrkonw65obsthuzooaxabb X-HE-Tag: 1694532437-517447 X-HE-Meta: U2FsdGVkX19ME0XRj3zowWgCG0Bo9IYOV3AmFmuFY26sGfmCviCalxSsJ1hndiaMhYx3gsn4KgwP/vYvzr7TlN5LXZw2Q41+Pncz6M6WHPqMu3XiNW0vsCBBRk1F5559dp5CENPC4/0LRsAEPO5WxkQLv9facj1y2q9NIvZDc2aPknirUMyAibNuw67lszwepSZ05YzyzZlluoUFe5f7FcaIu9Hlzh3qBs4Ml+5ijDth50kxbDpmaNig8s9GJn7xI+OUC+oFZLvVGk4pM8IWchVM+Ac1Etij0Cm3xyNFxfxD59v6KEgzHaTkChDMybVdgAVn07iulctbzhM7kTg9L8w7JDztiZy+RIZkUvwNpMm3Hcqad2LY2mq45H2R2r3P6asKcDoCI8EgMuPfk9+KPShMo64ERuzTCOBMUExxhhc/SxpAUEiw0vUvnAmjTvbHjrZTNWcTB687TS71fuapWMtnHDgfqp4j+jinwP0NqNZ/6WfGPOPhwOuk+adDNjaw94int+qDQh4ne4sCP+Bj4ZlOWkst2dm7dFCKQX/Z+42c6iLxLmT8PcxH/WcKZ9A10Y7Esmx8XDdmmST3Lo4sj+Dk7hUh1KNiDsZHcad+k5JXyN/tz7I5DaizXOSuEP6/waFQnvGjps7l8QO8BbDuTR4ffJyGHSxds8ZdtYTyEvg1QovpudzckTp7nNpRk73X0K43J4F8CLKJR7HpybjUeIMrY0EZ2OxOsONCgHfdEtrPsSQNYw14PFw9f4dz2c6LLLFGOmFeokhKWedaSKaM0otkozcY5jlBFI24riF2tRAMbUWYxH2kwyZoDdhjERedTNtmqFPbdLNaqbuZik3UYkRxxhTPnKFbui2Pm5U3aUNWw24Vqdx0E6WJLmWf9hfs8wxcVzz1u9rdf0dBf6pj7G2WSyyVRW9Forv9FEhl3BrbNqxwpQqyz+jpQD1etCQUJfe2Pw7FP5O2i6bkSk9 8UVupHGl RxhHuid0HEUkrd45/Ql+lutwO/t/3c7xid7pXAzUzwh0OKHz2jOWR53W2HCrPGjxkyWD0uSADw1YWiEj4Tye8wldgfHb8OjPLl2E/qKx7qc9s0jTMCK9tyfMu6byvFuYOgQk4hDco4ALAe4cZHyWjI0JPeiWezEAfeNOrT6xnxYnkYb6+ZG5uwPFKndb4rM629rMCW1xCXfUS0rG3f1u/t/+KNKurs3mTVmpHubixit9UXA1e12M577CgdvrnF1Ql+fViyeTM7cOPVTRe++JX0rg9Xbc90Gd98nXh1qL/U1ZtOt5LwYc/8vQRkexpsfh94UelRX97xhqUPa3tekbznOXjEw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 12, 2023 at 04:23:00PM +0200, Peter Zijlstra wrote: > On Tue, Sep 12, 2023 at 02:58:32PM +0100, Matthew Wilcox wrote: > > On Tue, Sep 12, 2023 at 03:52:13PM +0200, Peter Zijlstra wrote: > > > On Tue, Sep 12, 2023 at 01:28:13PM +0100, Matthew Wilcox wrote: > > > > On Tue, Sep 12, 2023 at 11:03:42AM +0200, Peter Zijlstra wrote: > > > > > If not, then sure we can do this; it's not like I managed to get rid of > > > > > muteX_is_locked() -- and I actually tried at some point :/ > > > > > > > > > > And just now I grepped for it, and look what I find: > > > > > > > > > > drivers/hid/hid-nintendo.c: if (unlikely(mutex_is_locked(&ctlr->output_mutex))) { > > > > > drivers/nvdimm/btt.c: if (mutex_is_locked(&arena->err_lock) > > > > > > > > > > And there's more :-( > > > > > > > > Are these actually abuse? I looked at these two, and they both seem to > > > > be asking "Does somebody else currently have this mutex?" rather than > > > > "Do I have this mutex?". > > > > > > It's effectively a random number generator in that capacity. Someone > > > might have it or might have had it when you looked and no longer have > > > it, or might have it now but not when you asked. > > > > Well, no. > > > > if (mutex_is_locked(&arena->err_lock) > > || arena->freelist[lane].has_err) { > > nd_region_release_lane(btt->nd_region, lane); > > > > ret = arena_clear_freelist_error(arena, lane); > > > > So that's "Is somebody currently processing an error, or have they > > already finished setting an error". Sure, it's somewhat racy, but > > it looks like a performance optimisation, not something that needs > > 100% accuracy. > > We're arguing past one another I think. Yes mutex_is_locked() is a > random number generator when asked for something you don't own. But it > might not be a bug because the code is ok with races. > > It is still fully dodgy IMO, such usage is pretty close to UB. My 2 cents here: I could live with Longman's suggestion of an rwsem_assert_is_locked that only exists if DEBUG_RWSEMS is enabled. Something like: #ifdef CONFIG_DEBUG_RWSEMS static inline bool __rwsem_assert_is_locked(struct rw_semaphore *rwsem, const char *file, int line) { bool ret = rwsem_is_locked(rwsem); if (!ret) WARN(1, "!rwsem_is_locked(rwsem) at %s line %d", file, line); return ret; } #define rwsem_assert_is_locked(r) \ __rwsem_assert_is_locked((r), __FILE__, __LINE__) #endif and then XFS could do: ASSERT(rwsem_assert_is_locked(&VFS_I(ip)->i_rwsem)); Wherein ASSERT is only #defined if CONFIG_XFS_DEBUG, and XFS_DEBUG selects DEBUG_RWSEMS, per Longman's suggestion. That's work for what we want it for (simple cheap lock checking) without becoming a general lockabuse predicate. --D