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 57BA4C54E41 for ; Wed, 6 Mar 2024 22:17:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C70E86B009F; Wed, 6 Mar 2024 17:16:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BFACE6B00A0; Wed, 6 Mar 2024 17:16:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9AC56B00A1; Wed, 6 Mar 2024 17:16:59 -0500 (EST) 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 944CF6B009F for ; Wed, 6 Mar 2024 17:16:59 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 57394C062D for ; Wed, 6 Mar 2024 22:16:59 +0000 (UTC) X-FDA: 81868025358.15.ECD4404 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id 34E7E1A0020 for ; Wed, 6 Mar 2024 22:16:56 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KAHb35XV; spf=pass (imf19.hostedemail.com: domain of jpoimboe@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jpoimboe@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709763417; 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=cNfaJ/SbpTdq34rD+dYmgvg3l8qbBt0ysk8M1vSjfvE=; b=N/g/pzxS+qNX9tH4VJBuACBP4+fh/tede362h5I84mlfHHcs8FNH+EtuwNLpF8/6Gi3bFU YgVMfkNk6DBnGZP6bgfk+QenSRUPQvn3tvA/IpBRVy5oWnJppaGCI5CfLEklueBAgcSwYX W5qZElmg9nCJFIjy1ax4SGj1hVP1Teg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709763417; a=rsa-sha256; cv=none; b=msVOg3K3tM732fAD+HztKf4vaLRKiIz5Dl27oYdFWxiSw4swFnwq64OVQAGdLk2LTHfVxU yJuBipI1j9IUdcgLKiWlFwiWGl0m2K+HP/4us7HyCMe/1Gykl9dxQB+kYLWz+KMurB1m5y mrRUK0MZPwVHe44wIdmmEIFsus7bOak= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KAHb35XV; spf=pass (imf19.hostedemail.com: domain of jpoimboe@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jpoimboe@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A3251CE2371; Wed, 6 Mar 2024 22:16:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71FBFC433C7; Wed, 6 Mar 2024 22:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709763412; bh=YM/H338B8M01FdZ46y0o1dHxsvV8JzksBNCBnoZtyNw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KAHb35XVNOAsbZEKcgCqU8E/MP7fIzvLwtSBgmbKQVVGokuSzV15djI/zw9fqrC+h m9/0EkQXCwKysGi/k11GzlM0JKQD+liQ57lPVMC9C6kH9TH+2nTLQPNuHWS9Lztpvp Ki6xJ8j9+MG/hjkAwl4rQ7RATa0xd+L5gZiv5c5iGNyvScuaFXD+kLvxcRmhi0cyr3 /ye6KLpPNxI4kEVBiT0Gq0uvSjXj6CCbfFrJ6GPTpmkxxgcYgUsxoGOCnAKuuQ8qfn GsuqPgBrUL7iTtH1rbsiqcq4Jc3DHxgvEhML2JJrDZOsLWe9XLpG9EuB3J6mvjWcbi Qvdl8uFDh99CQ== Date: Wed, 6 Mar 2024 14:16:50 -0800 From: Josh Poimboeuf To: Jason Baron Cc: Steven Rostedt , Sam Sun , linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, xrivendell7@gmail.com, ardb@kernel.org, peterz@infradead.org, linux-mm@kvack.org, akpm@linux-foundation.org, Paolo Bonzini Subject: Re: [Bug] WARNING in static_key_disable_cpuslocked Message-ID: <20240306221650.sw3lha7kca2quv63@treble> References: <20240306105420.6a6bea2c@gandalf.local.home> <20240306193101.s2g33o4viqi2azf3@treble> <854e523c-c467-47f6-b977-933cbaadeb62@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <854e523c-c467-47f6-b977-933cbaadeb62@akamai.com> X-Rspamd-Queue-Id: 34E7E1A0020 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 1cmj9ubrf9ucpf1chhou3wu9gs18wn88 X-HE-Tag: 1709763416-801925 X-HE-Meta: U2FsdGVkX19MpzGeuzTO0P6KjoxeDFhmut1qrwWg7AxpM9v1xMUTdoijKhEbiMd8Qv8WWATkSHmIe9tN+HwJtM2ge2ZViJnH7n5iUnhNupB30t1AVed2veNaRed2VKiztjBhbEvKdhWugFfCVlahiy+2v0bNXdSqzu4+BZ7baGExHvcCx9beD6ffFcJ86p0EmnYApUHHM4apTrkUjPqbLHna64Sscu9ndQh8ktKSSVW+Dj2EG0DjRjLwbNEFzFTcWsTnFRGdtz3BvLbEFO7EG1VfcSEEtgOrGyJxqw38njsx0rB5JdxhaUFa4b6pQ2a7k8oPl8d4lgDaLsZ1mklD53O1dwUNZMZpJ65ClHGkNc18nJO2ebXXbJeZ1oaXKXlFTJ3lqY0WuLhibXctThgQokwUznOj0VjiydVKg8/cY2az6WrP+m0oEZ9FkIpZWqgaGhqbCKjaUnv+srcbZBaMfrmUTwt6pHwIqEZle/upN50FB/txt7LAib+gAGss6WK0WohJmVt3htz1sY1pZ4lhiDfjYXoIbi3YUM/kP3KpexoDaXeiV85Fp2jJVXloLeZfQW4Yyrz6IwkD5rt1JGEY3ZtB+lQ5RF6s1YVkSj87B+p9GicQld5QiZIgQ7UUPvR2xIKWkLfiE+Nz8U2hgEuGHD0AyqzW9XwUP0CQm8sMFCm1tkXw3k8JibPbh32PJsyVinVjHKh234T5eCDdo0Qxg1OK1m+fECkKR2PTxlXDbTkZbcuHFBACm0Z1jiwzLRZbt4Xe1EXZOuV+SLY5+FVn/N5KINWQhfivQiuCoAcpAxe59uN06LDWwrrl9FRc2g2AM6Nyhc4Z1/3AXs5RvJERk7l4Z3Nz+jg4VVjI6DUGTDXHWLNYP27ZiTn1dDUr1IBc/G45E++CCujtfNXiwg7SnhuunRjStLL1bve1PQTcBZptx0FloDAZ2a8wjeRkyskbPw8lzlTjTxPMgWqktyo TW5o9F+N J31vkHkpk/QVS6CnYec72l0z+wTb6W+iwArg+WJr+n93OlR+f5ejH3cNZeDvB0ox7jX2tUknCmIZQsieOQwqEu9410mtgL15tbqP21aDcvP6rBoBC+D2mrcNEs6aAjG3LF4nFL+4hq/QHuTR/JQwlb/JWsgIbwFUJO7bgynPylyTcwae2cX7EnVN3uIT5OiynJDthbZHsKd35MuAskJGDntLQ9p9P12zGfuP45KLnzhdVS1o= 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 Wed, Mar 06, 2024 at 03:12:07PM -0500, Jason Baron wrote: > > > On 3/6/24 2:31 PM, Josh Poimboeuf wrote: > > On Wed, Mar 06, 2024 at 10:54:20AM -0500, Steven Rostedt wrote: > > > Now I guess the question is, why is something trying to disable something > > > that is not enabled? Is the above scenario OK? Or should the users of > > > static_key also prevent this? > > > > Apparently that's an allowed scenario, as the jump label code seems to > > be actively trying to support it. Basically the last one "wins". > > > > See for example: > > > > 1dbb6704de91 ("jump_label: Fix concurrent static_key_enable/disable()") > > > > Also the purpose of the first atomic_read() is to do a quick test before > > grabbing the jump lock. So instead of grabbing the jump lock earlier, > > it should actually do the first test atomically: > > Makes sense but the enable path can also set key->enabled to -1. Ah, this code is really subtle :-/ > So I think a concurrent disable could then see the -1 in tmp and still > trigger the WARN. I think this shouldn't be possible, for the same reason that static_key_slow_try_dec() warns on -1: key->enabled can only be -1 during the first enable. And disable should never be called before then. > So I think we could change the WARN to be: > WARN_ON_ONCE(tmp != 0 && tmp != -1). And also add a similar check > for enable if we have enable vs enable racing? My patch subtly changed the "key->enabled > 0" to "key->enabled != 0". If I change that back then it should be fine. > Although it seems like the set key->enabled to -1 while used in the inc/dec > API isn't really doing anything in the enable/disable part here? > But then the key->enabled I think has to move in front of the > jump_label_update() to make that part work right... Yeah, this code needs better comments. Let me turn it into a proper patch. -- Josh