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 2F07EC433F5 for ; Fri, 8 Apr 2022 06:28:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAD856B0072; Fri, 8 Apr 2022 02:28:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B360E6B0074; Fri, 8 Apr 2022 02:28:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 988F56B0075; Fri, 8 Apr 2022 02:28:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 8801A6B0072 for ; Fri, 8 Apr 2022 02:28:49 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5A58220847 for ; Fri, 8 Apr 2022 06:28:49 +0000 (UTC) X-FDA: 79332733578.07.8CDA10C Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf20.hostedemail.com (Postfix) with ESMTP id 6C9BA1C0004 for ; Fri, 8 Apr 2022 06:28:48 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id c23so7105592plo.0 for ; Thu, 07 Apr 2022 23:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Br5LmK6nq3U1CMGhLvbfnGvSCpmEH6bnjhJxgA+ANDc=; b=XRQxVTp0UjrQE+0dxzV3BWqyhAfGjYNmCmAfXmihCUoizoYiv6esmwTl2zufz8w2uP kLj3HlRnWG7m5O6kNpESs121XW5IY/kW+hdpgzcdzLAb1/czspF9wCBPnYcx+rgxe46f GbSQefCvNrszqOdMEfmu/i0Zjk1m+oC/zwjPybp710dYlPWZOQKTy66OW71m3+/vpjl2 E3r+vR8mx+4Le0EtD5aCcXD8ytwUV4SM5SgNZe2JWmmrbiLYu5InJrt+IucLBR4mXYA6 DLfIRloquRFlSwexHgXvx9m1N4j89PJamBhtXmIIbTo/pAWp3xuIcUwqgywSaN2K/T43 ciWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Br5LmK6nq3U1CMGhLvbfnGvSCpmEH6bnjhJxgA+ANDc=; b=JYBnvl/X8OOpyykjQtlPPEL32HiZYEzyx1GNJzdR5XLBFzi2fpkF9rcUI5vG6lYDKP 26XnoE5KJkLyHOlSEOQywdCwi23f8Upcor5eD5rA3PSp0/kHMz4+L+5pD0HfpeOHV3Pn seJ0q1RMxWXd7ZBhdmnIDxxufH7+sw0BTcux+4z/EVNiAR3q257v5c/CIc+vRPmCJpYL mEKWK6dwOU8SdM+htyDH6RWh3QoqXZfQuXhAkZOL3jW8cnZYox3oj+6ChqrCpz6T7whX L6Yhu+THHCg03G65dznnuKhqAZBZjnjw1E8G+GfJEhNWc6icxLCx/CBSAowa4iV0+nK4 AWlQ== X-Gm-Message-State: AOAM533RpHwljDn38L2okK9CfdF8uQrHVlMMfXgxr36rgKoD9I9rSOmy ay2jpaFZ5V3QOWwn2xi4cSWi3A== X-Google-Smtp-Source: ABdhPJwfPZEsuTJTC4HDVf3PL7Z0TonE+kb/GGzgZsL3jkkNuuCHjBjoBMEuLKkbX8IlVFZ730jUZw== X-Received: by 2002:a17:903:2302:b0:157:1c5f:14f0 with SMTP id d2-20020a170903230200b001571c5f14f0mr3711035plh.138.1649399327236; Thu, 07 Apr 2022 23:28:47 -0700 (PDT) Received: from [10.255.182.146] ([139.177.225.255]) by smtp.gmail.com with ESMTPSA id s10-20020a63a30a000000b003987eaef296sm20747184pge.44.2022.04.07.23.28.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Apr 2022 23:28:46 -0700 (PDT) Message-ID: Date: Fri, 8 Apr 2022 14:28:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] percpu_ref: call wake_up_all() after percpu_ref_put() completes Content-Language: en-US To: Dennis Zhou Cc: Andrew Morton , Muchun Song , tj@kernel.org, cl@linux.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhouchengming@bytedance.com References: <20220407103335.36885-1-zhengqi.arch@bytedance.com> <20220407205419.f656419a8f4665a2dc781133@linux-foundation.org> <35195a61-d531-aeb2-5565-146e345f8bf6@bytedance.com> <20220407211018.875696691e4411a7b5c8f63f@linux-foundation.org> From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: rqze1oosrqjo6s7a7bqznq3x6wm1msqj Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=XRQxVTp0; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf20.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6C9BA1C0004 X-HE-Tag: 1649399328-800431 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 2022/4/8 1:57 PM, Dennis Zhou wrote: > On Fri, Apr 08, 2022 at 12:14:54PM +0800, Qi Zheng wrote: >> >> >> On 2022/4/8 12:10 PM, Andrew Morton wrote: >>> On Fri, 8 Apr 2022 12:06:20 +0800 Qi Zheng wrote: >>> >>>> >>>> >>>>>>>> Signed-off-by: Qi Zheng >>>>>>> >>>>>>> Are any users affected by this? If so, I think a Fixes tag >>>>>>> is necessary. >>>>>> >>>>>> Looks all current users(blk_pre_runtime_suspend() and set_in_sync()) are >>>>>> affected by this. >>>>>> >>>>>> I see that this patch has been merged into the mm tree, can Andrew help >>>>>> me add the following Fixes tag? >>>>> >>>>> Andrew is helpful ;) >>>>> >>>>> Do you see reasons why we should backport this into -stable trees? >>>>> It's 8 years old, so my uninformed guess is "no"? >>>> >>>> Hmm, although the commit 490c79a65708 add wake_up_all(), it is no >>>> problem for the usage at that time, maybe the correct Fixes tag is the >>>> following: >>>> >>>> Fixes: 210f7cdcf088 ("percpu-refcount: support synchronous switch to >>>> atomic mode.") >>>> >>>> But in fact, there is no problem with it, but all current users expect >>>> the refcount is stable after percpu_ref_switch_to_atomic_sync() returns. >>>> >>>> I have no idea as which Fixes tag to add. >>> >>> Well the solution to that problem is to add cc:stable and let Greg >>> figure it out ;) >>> >>> The more serious question is "should we backport this". What is the >>> end-user-visible impact of the bug? Do our users need the fix or not? >> >> The impact on the current user is that it is possible to miss an opportunity >> to reach 0 due to the case B in the commit message: >> > > Did you find this bug through code inspection or was the finding > motivated by a production incident? I find this bug through code inspection, because I want to use percpu_ref_switch_to_atomic_sync()+percpu_ref_is_zero() to do something similar. > > The usage in block/blk-pm.c looks problematic, but I'm guessing this is > a really, really hard bug to trigger. You need to have the wake up be Agree, I manually added the delay in wake_up_all() and percpu_ref_put() to trigger the case B. > faster than an atomic decrement. The q_usage_counter allows reinit so it > skips the __percpu_ref_exit() call. > > Thanks, > Dennis -- Thanks, Qi