Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3411465rwb; Sun, 9 Oct 2022 04:52:05 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Ewi4zwVeWOz7QfOczEVIiVfTMD1fege0pmA6iSKMX7fiuKw+gQHFHelhjMGVpI4N8Bna8 X-Received: by 2002:a50:9991:0:b0:458:a612:bf5a with SMTP id m17-20020a509991000000b00458a612bf5amr13304624edb.22.1665316325379; Sun, 09 Oct 2022 04:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665316325; cv=none; d=google.com; s=arc-20160816; b=l27f+MPjYzBIoNk8xatNhfUUvAlg3/G45jzSvDYW5RGjey+DcZlamu2yR3Mo3jso6X ACHGTzhc41JR6S+m7HFlHjRma1cunBdCXzgDc4eMLvKtlSPn2IIdjAbrc15KlWRmIBdj /4XBo2b61vww9lwRTTwgpkfBd44FzoHfyL8ppGi9oKx5iKYqv5yBKYdcg6c4BfNIMyJD eupGXwGh3ic7JwqHq6RkWmXsxv4HWp7xOlL9pTWQ8NLFoKapCGKfAqrXzwEG+Ve9Q8MX Jmqdm0IF1XilcWhumbaalAhTTrjOtETjsyGiy2kM3EBkDwmAuworJBxWixCIUTeNGXDV zojQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=twlFTPIFExHcgABlKji5EDqvNoVPZc6QckzjgiZRCPw=; b=rAwtuIXSWr4QwhkiAL0diVeXkWDVyfdtCO2bcuyYrxDQu7ddAL3Cnj3HLeU+JCJn+D 4SyTWWCDUdTA5WaLrgmnPnk/P2AG06/KIBPe7G/5on4N0QRjwwiG9WFOLMNnf8VO9M1q v2D25E4jglP/iDOojQ+VOLZTIYcZPMO3lYXYxHwFs+wzla/VG7WyRK1oEGL6dKNp0Zap KZOOaQKAyFii5z3ytNRU5uEjT6nhV/ov9CYFtkDcv2NeBeWVMzqoRy+Na/YLceknAYPh Uy5M0yWMycHjvXhpiqld7Geu+PkzgYfIVepm+2fcvRSdoXAWXjawcMZGUTvAnecxUSz/ kxow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=UGKR098v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q18-20020a056402519200b00458abbeb000si8098852edd.300.2022.10.09.04.51.40; Sun, 09 Oct 2022 04:52:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=UGKR098v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229992AbiJILps (ORCPT + 99 others); Sun, 9 Oct 2022 07:45:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229602AbiJILpr (ORCPT ); Sun, 9 Oct 2022 07:45:47 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9FA92D1F7; Sun, 9 Oct 2022 04:45:44 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id l8so5338103wmi.2; Sun, 09 Oct 2022 04:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=twlFTPIFExHcgABlKji5EDqvNoVPZc6QckzjgiZRCPw=; b=UGKR098vducQiqq4/PQbunNJ2hGfJXz4KQaCyWsRxBICM3PvRHp89/Wj03DvX7+X1K fyPh2bgcJVTDMYLpis98gCCI63OLSM69Y92qoDsOtb87P3UELz36TL+5+7E5hZZlZ7L/ A5Sm2U8Gey5savLqZmNLcy02bc76zBHyTbebi/4scv8tppjnhIOGOa2x+YkjE1XOcqqo fR8jORfrTWxatLY96KO4zG3gz00wCjVE5HjLQtCYywp/BKw3tfka4sp/iXm8GpWQ/nO+ DJpIZuy7W+0hdf3/SLhXewHxwbddjGOve/3uE8hdjmT94pPAGRxZEJ2w/r1jio2x9/rq ze+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=twlFTPIFExHcgABlKji5EDqvNoVPZc6QckzjgiZRCPw=; b=Q3tr09RHxIScsTQM1Q+MjwtMbZXtv0wioBSGKKwmyZ7qeKWkJscqqYMHstnWJp570O X7e6/cDrfN3+Ye0CELS3432hiGT3mW++vs4CEhXyIN4lG/nm8FUnm0YWmTtHJ52jaBvC m2ruLeRKMXp5H0h83PMygYhDyRJsnQGttmo1skn5M0Un28hjbuVJM4Nw5HGiOWR/0I77 kxo2PalqTLUskRFIsq3kiHoqd2Y/RHMNxkY9sMkxVbR69Sh24vPT7xW7xd4hTbfRQgWP pYzR5f/V00C2yF3HoHQENqKtuaBxtAdm7G6iamrl5bLru7QAUG/bEwH2WJW+FWGOGisj UiRQ== X-Gm-Message-State: ACrzQf3GY4zuPW1t/R2tsv/aInNRo+wi41C4nqOqM635IOYTEZW46y1K AeotJFagoOOAP12D0G+UTNTvoupWcoVhVftLL2DvcrdhjOsp5Q== X-Received: by 2002:a05:600c:474c:b0:3c5:dbf4:ba94 with SMTP id w12-20020a05600c474c00b003c5dbf4ba94mr1769939wmo.21.1665315943302; Sun, 09 Oct 2022 04:45:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hao Peng Date: Sun, 9 Oct 2022 19:45:31 +0800 Message-ID: Subject: Re: [PATCH] kvm: x86: keep srcu writer side operation mutually exclusive To: Sean Christopherson Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 8, 2022 at 1:12 AM Sean Christopherson wrote: > > On Sat, Oct 08, 2022, Hao Peng wrote: > > From: Peng Hao > > > > Synchronization operations on the writer side of SRCU should be > > invoked within the mutex. > > Why? Synchronizing SRCU is necessary only to ensure that all previous readers go > away before the old filter is freed. There's no need to serialize synchronization > between writers. The mutex ensures each writer operates on the "new" filter that's > set by the previous writer, i.e. there's no danger of a double-free. And the next > writer will wait for readers to _its_ "new" filter. > Array srcu_lock_count/srcu_unlock_count[] in srcu_data, which is used alternately to determine which readers need to wait to get out of the critical area. If two synchronize_srcu are initiated concurrently, there may be a problem with the judgment of gp. But if it is confirmed that there will be no writer concurrency, it is not necessary to ensure that synchronize_srcu is executed within the scope of the mutex lock. Thanks. > I think it's a moot point though, as this is a subset of patch I posted[*] to fix > other issues with the PMU event filter. > > [*] https://lore.kernel.org/all/20220923001355.3741194-2-seanjc@google.com