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 41301EE49A4 for ; Sun, 10 Sep 2023 23:17:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B32A76B0157; Sun, 10 Sep 2023 19:17:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE2186B0158; Sun, 10 Sep 2023 19:17:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AA4A6B0159; Sun, 10 Sep 2023 19:17:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8A76F6B0157 for ; Sun, 10 Sep 2023 19:17:39 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5A06912086D for ; Sun, 10 Sep 2023 23:17:39 +0000 (UTC) X-FDA: 81222251838.07.0415BF0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id F2C2780012 for ; Sun, 10 Sep 2023 23:17:36 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Mw7H49FQ; dmarc=none; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694387857; 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=JHcf92QPbpxoV/BDIrCkFuoFwIyJCmqYEbR7oacx+1c=; b=EJBkPxpDzE008si2r7p4aJR3huXQov7yBhvP2aciXv8tgr0K/adx82sTZgXU+bJdRCYF+4 WPbrMw8mLhMgc3530yqnaGapU5JHJtz2trNpT9Rmzfvx5wU07b3qgHte51Z/bTXZJdYVGd VjptXcYx0GWrC4JUftIg75ELrRv5k+A= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Mw7H49FQ; dmarc=none; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694387857; a=rsa-sha256; cv=none; b=ENb81dJuGvC7iXGh3nCnjssIOs6Hu10YSQHaobQR9NG8vOepEndgSA+R7u1mSMFH7k5+ND xVspbb/Gf+unNzpY215VNcJD28qwpeVIg2pDc8OzSboROtmR5AHFk+uuHJHImgc0P0PBqw 4nsXvBU8EhLBS4zL1EcgZbB97BCVFhU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=JHcf92QPbpxoV/BDIrCkFuoFwIyJCmqYEbR7oacx+1c=; b=Mw7H49FQH/Z49w/0iLemxbe5Nz J23I+cbhm7wO9uB6syLHmvg6f0VeXgDkYsaHReYvbd60gjKD8dVpdMVtX5jr42zd3nwxYytL7G4D/ EcZ2inJz1QOkexzBFFUzC28mbR+DeeJAcf3I/56spPxi7HOlHN//AdRwAbvV5D08wWe1S1Vdl92nn teTxdQY3LpuSstD7FdPzbhk5bjmhNski0x19lFaNTw7a1EXn5m8rXTWguNYTq7oSBMF4/EoYzM9NG 1LdokbVprnuQ6R7ND25ZWT/uURTLLX6I6djRMpJ0JlSvV2Cb94JyWK1alcupIqWWZtqGh+pO+CV74 jhAETjfQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qfTg6-00F80P-V0; Sun, 10 Sep 2023 23:17:19 +0000 Date: Mon, 11 Sep 2023 00:17:18 +0100 From: Matthew Wilcox To: Dave Chinner Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , 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-1-willy@infradead.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: F2C2780012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jwsnr1t9phhjwy1fmnrgwonngn87ree6 X-HE-Tag: 1694387856-967029 X-HE-Meta: U2FsdGVkX18A33/7E3c/+Y+cwSdHqHnFRWrCO+N59TjPVud/nZCqH5XWQibu3Nrt7lmKAJ2b0czY3XQdE6F+2Ji4DFG+zIVxOfNGGNECpwYJH3/AdIitkUWf99OaLs6deEgCBO2puED48zYXqFO2dKKYpF/yinneibkcbyBFfnLPWRe1xBKHo4ZoKur7zB2fIyp0kyWa3Fmqi8jk5gpiL0RUt4rT/rYakBpyPoSv7ds0nemmb2wkxl6bA8rr43MwilDo7UJFK4pBM8NS0oN5BnlaDt5sgu6CwlYTG+aWN2ZWstQBNv8Z2kF1H6JxrNWGTiw12etDOtrIj6rEhpoQS/zynNxr2SZFaBy7PXIdUaYJT/fZhKzK+aL3WXikb7j1ndGzQftb0+u19X2RTJV3AG3D699eDkcDD8i3k3pmH+djaVuTn9pg0Y9aq76fZ/8CN64959i8EImOrv52O7vvvpwFAS/aGGgKmftNXf8wyng7UMhcoP/dARRXuqgXxNB48a6j1SVw+xRhuUWukQU9IhZ5ok/WJcPjGKrOnIr3qDeB9u9fUz4SqgjiKoxvryjp+JQFS5rumAhM9h/5i4YFJPuzX1v7J1CECqAsQaiZkjD3mvBzhgWLRCEO1BEdkJ/UwXMZ77ajeNghyU1XGBN5IGF1k/iHuBvbIbhd8m4smY0hXUP+z0as9lnq1Mk+eXRfxJwn6kPq0Q1AmFRjCLTkZiY45kqcf7VPsS83+e8Bkai4tOtXRMdEr3n6+zuQsjnMrZdnJNh5XMkENf/6PLopd4VgCpOaLIiwWPpS8InW/Ha53sW91XAORng2Nd+vpraC9ehKeU47WIOMdVxJ+qMgauICE/g8LeUnPYWSxvKRXxww62NOb7E2AZcbeRw8fCCesJFNrec+zczRXnVKFp5rDSGIgSAjvnv26iXbT5GIjjlp674TEs27dUhHB38Fi4tyZ5Mu0R6iUfIhYZxfy2a G4V3S7xf +yLqP1hsig3gq2XAen4W/MnKWnoT7LAulOxYXl08eVZoOzUJnMaYbNtVTr3sIbu5p1moX7YdwDn/6f/IdwPdV+cWJMdntV6FikWk/5XU7K2Eq9HRaoops7Py7YRwN5HggXEAbJaMMgocIE/pBjlwVNTShY9niXCiKEeGGW7oAUDywJDIvlsJOy255mg== 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 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 ... 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); } but then we'd also need to change how XFS currently uses the ASSERT() macro to be ASSERT_LOCKED(ip, flags), and I understand this code is also used in userspace, so it'd involve changing that shim, and we're getting way past the amount of code I'm comfortable changing, and way past the amount of time I should be spending on this. And then there'd be the inevitable bikeshedding about "don't use BUG_ON" and it's probably just for the best if I walk away at this point, becoming the third person to fail to remove the mrlock. I'll keep reading this thread to see if some consensus emerges, but I'm not optimistic.