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 43344C54FB9 for ; Thu, 16 Nov 2023 16:12:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABB866B0474; Thu, 16 Nov 2023 11:12:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A6C016B0476; Thu, 16 Nov 2023 11:12:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95B4E6B0477; Thu, 16 Nov 2023 11:12:48 -0500 (EST) 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 8A2236B0474 for ; Thu, 16 Nov 2023 11:12:48 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 647A9A0C74 for ; Thu, 16 Nov 2023 16:12:48 +0000 (UTC) X-FDA: 81464310816.06.F930134 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id E7E14C0011 for ; Thu, 16 Nov 2023 16:12:44 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=G2Z0gmyd; dmarc=none; spf=none (imf28.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=1700151166; 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=Lz9jtIq5mDaKC570N2BIf9wLXeeJJC+HK/9/2AmFe2Y=; b=TW67o8xquaBWA0zyjRvhoRIomDG9P4F9uiOKQb+fFDhkkeYyktOqkoLO5Fr5WY4y7AD62E bURSrOTuywmJY7F6lOgX1NX8VK7pDmrAjTAVbI1ci7ywu6XZLYzvVmoez6hPgWwoYTOU6p UptF5BFOWY0UZMPFi81jLN/BEpOVGO0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=G2Z0gmyd; dmarc=none; spf=none (imf28.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=1700151166; a=rsa-sha256; cv=none; b=8k5Ssl5eaprtT5ME8m4weZd/92Jo51ZQ/M/jxGFI6N3BljsDmPu8BSdejPz/6TusrmffU0 8YFg34Y8DG79UhXrf4GR5JZRXDrGd88AyDjaanTFyjdNlNkyp0CyaghGCXSwU1IPmBenJX p4pAV9KZiqPFXL7YAQydmeOjc2gD+tE= 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=Lz9jtIq5mDaKC570N2BIf9wLXeeJJC+HK/9/2AmFe2Y=; b=G2Z0gmydhvRGXv3j/EgJ5/r98/ JRxc7e8AgM7fcqr96CRTx3YKpfFGomG45ImrBNZ4AcVV1FfGosSfbRC8yoKwzUj6ZZbW1dwZEF7S4 q9qEE0dqulvK+qgxAnWkD5ylAReeUZnnN9FJBEvgMiegE5we3Dt2xxNSrAgFUeDvC8ZYpcHZSfaAY QpEkCz2mMV0vk0HaibcjqwOhi2V/t85uf+djkOoj0Tdn4x4xy9hoYGPpfpvCoXh3JKgS3kKiDjS1H PTtt0rwS2L56Vez7EpKXi63vls+6/KPkNwFRKl+Plp3DJPStTfQ0XtXhIVmG1mC7+M+g4rxhvVT4R 2sHkY/FQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r3eym-003xSV-RC; Thu, 16 Nov 2023 16:12:32 +0000 Date: Thu, 16 Nov 2023 16:12:32 +0000 From: Matthew Wilcox To: Waiman Long Cc: 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, Mateusz Guzik Subject: Re: [PATCH v3 1/4] locking: Add rwsem_assert_held() and rwsem_assert_held_write() Message-ID: References: <20231110204119.3692023-1-willy@infradead.org> <20231110204119.3692023-2-willy@infradead.org> <52f481a3-bf4f-85ae-9ae6-10a23b48c7c5@redhat.com> <72dced0f-6d49-4522-beeb-1a398d8f2557@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72dced0f-6d49-4522-beeb-1a398d8f2557@redhat.com> X-Rspam-User: X-Stat-Signature: ambje4ximjiyw86nognoi9wjz6jdubtr X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E7E14C0011 X-HE-Tag: 1700151164-703762 X-HE-Meta: U2FsdGVkX1+EPNpjOvh/V/JyleiY7yRJvB7DoIXUJKGfhQ+ZKmSYcyu286eKxTcZ9LnGSuNyHlx02gZnsjqZ3rldZlyqDMfqZBM8GLaFYsBSdr4qq2yyyHg/oAK926Z6weELSG+s9vQ8NpaQNRti6dBl8Uf90Wqak7vmDYDnMtRb5OQCGzjkxA5uFOjgDMVXV1J4zNRiIisHJqX5UZX6usTIOx7NQtOFHv3fwZOMgd0ZE/8SMt+4YGXODD3bAKOKZZiggadeYd84sGkqmIxFA2eQ5nXkchtE42s1M3/b3WNOFceoqDaWUfMtOWudA+cfvWm36SfWd4TPhYzTHuc7z2W+nQVeYHoIkDGRcepVMGDmR1J8UWQstzebRGWzF5TvAmW0Ao2Ca7u5UevlGffSMBK0o7EA/2B6xLWWz6D71fkzD5PHWZlyDTbjQjZjxUXHk6U5iGSz84lETyVxd5CGByGEFplVlrTCWG0KoHYagfZrQfOb4dK0+VlJsPgunYg798F4abplsze2t7q77Ga8U1s7jaurdDb4sV+IcVzR4FlpKPpWGkH+rCG91OazrWwPuSKB3iY2FFMg4Tk23OGzgYcP3FyjMbZ/nAt6+v31yM9Dk1rnQWpP/8CGiaxuNs4UqPuQEZGiv9VFX1Ydq+L4g/6OkwPSKbgLukiEXrQj8kHNGfoFTobuXzPGBi2PF9y/K+UbiA8MJtT2Z64EHkgb+yMmnwCbnwHJMcA6pD9wojj/IdTHVQiIxFslJjkdJZU2DuIx3eW/0Q1B7rqqETrNEb1XTBG0/eyQLF8XPWsM1iEv9XRQnl5bDsVOZvuV73aA/yjS7ZMq6e/w/LNR5JJwsa6l1BokWJD/7qqC1Q8x0fXbN6IfE+dQb9mrm538MrhKS+FMxkjtc4B1oK3N+lBkWD/FWLybzjVwmqI62WT9IaQ0BMsK8/KRAmPNEwHDNub+uCy2enV2T0zjZ0GxDj3 3W7yVvUr C9llA+sv5vzJ45qsnKVpVddzzI9Bnid/WuxiM19GEDNHvuzcyGmsxqjYA4RpA1LifzMCUXS/bmELt10EuUx6YnEq5YCeivM4KZs5z4Xz3QoSIL8YhFSX5ocLQNFgAYjJ5ZY2S2mPnjU3xhW/Nft5M9JLo2FjUs+JCufn95T/rNjV8U/p7N4KZnn5wCA== 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: List-Subscribe: List-Unsubscribe: On Tue, Nov 14, 2023 at 08:17:32PM -0500, Waiman Long wrote: > > > There are some inconsistency in the use of WARN_ON() and BUG_ON() in the > > > assertions. For PREEMPT_RT, held_write is a BUG_ON. For non-PREEMPT_RT, held > > > is a BUG_ON. It is not clear why one is BUG_ON and other one is WARN_ON. Is > > > there a rationale for that? > > I'll fix that up. > The check for write lock ownership is accurate. OTOH, the locked check can > have false positive and so is less reliable. When you say 'false positive', do you mean it might report the lock as being held, when it actually isn't, or report the lock as not being held when it actually is? The differing polarities of assert and BUG_ON make this confusing as usual. Obviously, for an assert, we're OK with it reporting that the lock is held when actually it's not. The caller is expected to hold the lock, so failing to trip the assert when the caller doesn't hold the lock isn't great, but we can live with it. OTOH, if the assert fires when the caller does hold the lock, that is not tolerable.