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 4EA37CA0EC6 for ; Mon, 11 Sep 2023 22:30:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A89CD6B00A8; Mon, 11 Sep 2023 18:30:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A62116B00A9; Mon, 11 Sep 2023 18:30:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 928496B00AA; Mon, 11 Sep 2023 18:30:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8433D6B00A8 for ; Mon, 11 Sep 2023 18:30:03 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 47DDD140B2C for ; Mon, 11 Sep 2023 22:30:03 +0000 (UTC) X-FDA: 81225760686.24.7D6FC9D Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf09.hostedemail.com (Postfix) with ESMTP id 509A7140014 for ; Mon, 11 Sep 2023 22:30:00 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=AmYbgjHq; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf09.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694471400; 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=ok19BPXq/ZtE5Je9WteUjIQMcW5gGGmyf4q0shWhFBg=; b=wikraoLEPQFEpiqLcKz3kenyIuAERdvNEPGT6yhVuhxHAmhRq9tqpQZ9MQr8HamM4tevhU o7evxuKLpLU7SAi23nxWgeE1URt8XM4xK4jMnBgMThWDcuMUkJq9U4vpQeqaRyqqauOVkz aug69vVXJ15IcM0eusTNwn+leCoCmv4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=AmYbgjHq; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf09.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694471400; a=rsa-sha256; cv=none; b=rwbsBNhBgMMWoBxyxQk5ZkENUEvngPIy/aGzqGn3UmycKMqNVIN9kU/OuKfIozwzXHhxmw 3lfSkphy3JLUA6Zuo0hhnNXiy0BbsGxu8ChzoRbV4JkXQAf6gEI6TAuf5Fz/SBZVHudPLr N4KBC8rCFUBtrC8jwwa8hxgnjwtzbGg= Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-5774750a6efso1570342a12.1 for ; Mon, 11 Sep 2023 15:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1694471399; x=1695076199; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ok19BPXq/ZtE5Je9WteUjIQMcW5gGGmyf4q0shWhFBg=; b=AmYbgjHqJiqvLnk/dH5aiO+7nNIIVmqEB6TG24occZz+uocFKkI9R7OQCMVKzhaRv+ 525AcOeRDHRxWdGIpy8xsMO96Can8bqHX19aQo+Ldo8ZRkxPE1cw+x/6nDTR+Iq0e2Lg gnE2j+wFv9CTFpEseAqnTkGnkK6p917MeG/G5iDes4XnsBbzuTOPQwEZwPbKglbsBLE6 OuXzXpZjeRxoWpaCFGmazTS9GUO2eXoYk6hXVyZXCjI5mmtwuo9Iyly3jq+kcjn82z4v ZVp/lhELmaews+xVF2qX8jzEOngVVWIObVJO5xyJKZ3FzolL+Guvmo21Acp1V/Tt2a2F 0kpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694471399; x=1695076199; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ok19BPXq/ZtE5Je9WteUjIQMcW5gGGmyf4q0shWhFBg=; b=YnrvtdQWOs8DOykktmG6NBi/hDD01G9VZArUGiB62Po450jt/HdKlKazN+h+WRdqeI e9J2m/4XgTjxHvU0mQJEy7FootpCLbZxbdwvs2eel7+B8XdtqSovVzJLEyWKuTps5XGv nnYsZbHs61FWIKX/ftFCLKoRHHkUi5mhmhXOoEfl/6kcIgpJvcbD429V7/hyrjQd2AfP 8diXA1A9rpFIDJ0tWUr4C+Amh6yIpPGQpcZECHPE/tXLlLGW3CjeRT836s746apoOffY SOLAWyBgSCvgW+Do7ZsRNVeQ2dxWd4Z+7UKZw8d/lzWDPKn6OE2xQlKM7E+RxmocGzBZ FpEA== X-Gm-Message-State: AOJu0YxunmKDsrpdH7gGTcy8yrMSjaOnN4QWl9Iq7L+jNXhNvHWhcvoK 5waPyLao/m84BmvqIBRwlHSwHg== X-Google-Smtp-Source: AGHT+IE/LaOllEbOYogtobKnQv0RIkvkE2D1hgCfX1NOJa1hWXTzgr9ZPscNFI5RdpRx8ePwENieLg== X-Received: by 2002:a05:6a21:6da9:b0:148:f16f:113f with SMTP id wl41-20020a056a216da900b00148f16f113fmr10528676pzb.12.1694471398931; Mon, 11 Sep 2023 15:29:58 -0700 (PDT) Received: from dread.disaster.area (pa49-195-66-88.pa.nsw.optusnet.com.au. [49.195.66.88]) by smtp.gmail.com with ESMTPSA id g14-20020a056a001a0e00b0068fba4800cfsm2979220pfv.56.2023.09.11.15.29.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 15:29:58 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qfpPn-00Dy3W-0c; Tue, 12 Sep 2023 08:29:55 +1000 Date: Tue, 12 Sep 2023 08:29:55 +1000 From: Dave Chinner To: Waiman Long Cc: Matthew Wilcox , Peter Zijlstra , Ingo Molnar , Will Deacon , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chandan Babu R , "Darrick J . Wong" , linux-xfs@vger.kernel.org Subject: Re: [PATCH 1/5] locking: Add rwsem_is_write_locked() Message-ID: References: <20230907174705.2976191-2-willy@infradead.org> <20230907190810.GA14243@noisy.programming.kicks-ass.net> <20230907193838.GB14243@noisy.programming.kicks-ass.net> <20230908104434.GB24372@noisy.programming.kicks-ass.net> <70d89bf4-708b-f131-f90e-5250b6804d48@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70d89bf4-708b-f131-f90e-5250b6804d48@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 509A7140014 X-Stat-Signature: cio35fmdkwoqgrscf4cx9pim54ttkadx X-HE-Tag: 1694471400-598238 X-HE-Meta: U2FsdGVkX18lMxViN7NvGpXNjiRsutp4iGJnlJnn19UoMpCnIzSHHqmw6MviDNrPcoJ6AiTvP50Hn5/CfbtSqT219fOdmbFmASVKD7lhIP9Th0WrFDODqeRPUcxv6p57M1sHNkcG6Y9OKqZARIYc8Lvu4EL5RPQETMtH5B6ePSVmqBpy1f+yPYYlvkoLlMIbcVjN1y9ZbBMTmFvSRRoOKU6ULSygUUOLwVSBYd5rN4UOG+8/9+sUdGLqWR8AhnryJJn3afj+2tPnmataX4jUUjNufeLPHlH6RkO+oQRuI2lvutHKRInAmxngQ/d2Ha6g80Ty/wFJyQjawIL7DzhDRoOhLJJ7B01klf14+Y5Qcjnf0QNFTLTnXVAzrMZ4y8vUF9T6JLg84qoSsA+PQ8dQBX4gw6WqpsnF4gHZaEuPvAOI3nvGAjj911Fa3d/tEtT68ixyddWgXEJ14w4FfCebUKz1fRhuIp60kPE2wYs9v2RML9TJ5gl7K8zell5gAVr41y53DQBxZIyJBVrThaldjP9CUPQI6Wg3WFH8PvsPa0mdZlLsZTsOP+AZXFYO7p80JhXuCahjfkKFOc+eNC0L0UR/voKCF0I7LDumXSW7n0g6ce9mLkic6qSgYjvf0KDFLQhfWqLBT7KaGLq0JOZvFbr9DhprKrtd3rjttAnI9NrDEnkjkNsSdSQo1SGuUmINSWXIQYCtOaUjUzjyG+W7lt03i2TXu2+fUGhEuaGoUKM8yLWXDAd0SXZ5fb9zUZeCpBbrYFI9M3e8003p9WUm3Usfb4p4oyOUfQ77aRfslB2xzydo0Ly0MydqytqauYoTa1FuifxGoVYyKPr9MXIVXKjylW0PxNadfv3L4N8Z/C2ugEoAKPeVU9psK2hgd5XppWNfzPeaUgiKmTDVHHE8mejuE8EGKvZT1Q7BwAPDc7jHiN1JFnb/9DmJ2iqe+XfzD5j7qyrJqWowV/IT1o7 stYCNCAG yTecq+sylnspxL04IRDGTSmBmzT8uLGUD9l9P9Gc9r4aiAtwln26Eo45yu85I7DokH6ixV31VNe86S2ckuC+O19i2DcRG6m34nYLslFob6aAH4YG7oa5h/aQQsXldC97YJGucA/zNTpQZRb2jB8b5dXQttB7tWMrsI12HDcErjAz9woIyPL78zgDbm1vshSVtOWmE/Mk0zJIMZDPFBpCEzIAA8vmbRDWrcMWSXr2+vIFAbZRnFdn6/8D7Ipm3k4B+H++cSLH/bqpHKbKgV0Kh0dTsT+TpGj9S86kXjNkbrd4ObdRGlvGagoBRwRh/FgZRCeoGChzOYfaXfrbWZo+anOYuqGKTCVV1Np8Rnsml+NQD6/LRbvR0ZgufoIniYsvGaF71v01/MTL0LFEMv4lKB+f/Z2CyQjmv5ZE9IWasGM6qGBxWduJ9yfkApmluNJpuYbMI5DtvjxdHncaPfxcU0S+zSNQADZtYEkul2hBUEIvBcX9Yv3oSmmt8TQ== 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 Sun, Sep 10, 2023 at 10:15:59PM -0400, Waiman Long wrote: > > On 9/10/23 20:55, Dave Chinner wrote: > > On Mon, Sep 11, 2023 at 12:17:18AM +0100, Matthew Wilcox wrote: > > > On Mon, Sep 11, 2023 at 08:56:45AM +1000, Dave Chinner wrote: > > > > On Fri, Sep 08, 2023 at 12:44:34PM +0200, Peter Zijlstra wrote: > > > > > Agreed, and this is fine. However there's been some very creative > > > > > 'use' of the _is_locked() class of functions in the past that did not > > > > > follow 'common' sense. > > > > > > > > > > If all usage was: I should be holding this, lets check. I probably > > > > > wouldn't have this bad feeling about things. > > > > So your argument against such an interface is essentially "we can't > > > > have nice things because someone might abuse them"? > > > Some people are very creative ... > > Sure, but that's no reason to stop anyone else from making progress. > > > > > I was thinking about how to handle this better. We could have > > > > > > static inline void rwsem_assert_locked(const struct rw_semaphore *sem) > > > { > > > BUG_ON(atomic_long_read(&sem->count) == 0); > > > } > > > > > > static inline void rwsem_assert_write_locked(const struct rw_semaphore *sem) > > > { > > > BUG_ON((atomic_long_read(&sem->count) & 1) != 1); > > > } > > We already have CONFIG_DEBUG_RWSEMS, so we can put these > > introspection interfaces inside debug code, and make any attempt to > > use them outside of debug builds break the build. e.g: > > > > #if DEBUG_RWSEMS > > /* > > * rwsem locked checks can only be used by conditionally compiled > > * subsystem debug code. It is not valid to use them in normal > > * production code. > > */ > > static inline bool rwsem_is_write_locked() > > { > > .... > > } > > > > static inline bool rwsem_is_locked() > > { > > .... > > } > > #else /* !DEBUG_RWSEMS */ > > #define rwsem_is_write_locked() BUILD_BUG() > > #define rwsem_is_locked() BUILD_BUG() > > #endif /* DEBUG_RWSEMS */ > > > > And now we simply add a single line to subsystem Kconfig debug > > options to turn on rwsem introspection for their debug checks like > > so: > > > > config XFS_DEBUG > > bool "XFS Debugging support" > > depends on XFS_FS > > + select RWSEM_DEBUG > > help > > Say Y here to get an XFS build with many debugging features, > > including ASSERT checks, function wrappers around macros, > > That may be a possible compromise. Actually, I am not against having them > defined even outside the DEBUG_RWSEMS. We already have mutex_is_locked() > defined and used in a lot of places. So this is just providing the rwsem > equivalents. So, once again, we have mixed messages from the lock maintainers. One says "no, it might get abused", another says "I'm fine with that", and now we have a maintainer disagreement stalemate. This is dysfunctional. Peter, Waiman, please make a decision one way or the other about allowing rwsems ito support native write lock checking. In the absence of an actual yes/no decision, do we assume that the maintainers don't actually care about it and we should just submit it straight to Linus? -Dave. -- Dave Chinner david@fromorbit.com