Message ID | CAPm50aJTh7optC=gBXfj+1HKVu+9U0165mYH0sjj3Jqgf8Aivg@mail.gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp498665wrr; Wed, 7 Dec 2022 17:20:17 -0800 (PST) X-Google-Smtp-Source: AA0mqf6PVxQHE30iYcTf8knPr4n+nNq4r6YF+qPftJ9NF49tOd6FLsDX3ybYaArNGqkqNzT+Oouy X-Received: by 2002:a63:1f48:0:b0:439:db5:f817 with SMTP id q8-20020a631f48000000b004390db5f817mr67977558pgm.310.1670462417400; Wed, 07 Dec 2022 17:20:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670462417; cv=none; d=google.com; s=arc-20160816; b=yJFXyhELFmYtydVSqMFQR+orkNSNYUkZfw94QBwHfjYeAxdKbPhS0p7Mqxcz9hKFt2 sSDnKO1k3WXcVGZXW7i8OyPGxXwjyti1QAeS0XIyTn1bo9SNh8XSoY5v958S0KoDdT3a x9umcMxLAbhVdW8JtCGr4VucI3bSeDdMPfCtZXhTqCWIFj3wsVn1fzi6AS2MQdEIRnug TwnwJ6OgDXNmxO6230EwoEES0xQ2ly3eEO2n7TYleFSZe5N6ipcfqi1AVGSTROyJWcoo dUSRi+FLet6VxRTLAcThHgPgHmvB6tPVXJwXGSpjeQCjSVtuqsskhpBHdvCmP3v7kfG7 2mpw== 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:mime-version :dkim-signature; bh=F7aBLr/WPCbhlzqY1hJmfvUDhrJb2eGJyyyPzfEuW20=; b=k/uDIPA1p+OZZ6TrtRiqRrQMCOJQ41ZsI98lVVXDOBt0BQdHZOWwVbeURNwqkjeK+N rR6TR5WJdamp0eevkYWmgZNaYqnCz+27e2W6zFI0ul67ohwHo7CVI63BYTgzhTRbIhKd Zbm3xi/Oh8ClhKaCuKLl+nQ/GEzt+3lcT0wikrK7H8ZNsPhCDuQG3/wnaPTkKNrtYEPL nXgLZ1Cs1B1S1/7LREcists37atC2uw9/5syVpzb/x4K0P7F8QxijnL+OceyzNYFMlIK npfAp4Cj9BLAAYevFyALLucqgdUFJRrExoTd6tZGWs6vqPTXi/gb5Z/9SrT929izVID0 YMVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=LO2BdsfL; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b9-20020a170902e94900b001890f0086b7si20664065pll.454.2022.12.07.17.20.03; Wed, 07 Dec 2022 17:20:17 -0800 (PST) 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=LO2BdsfL; 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 S229684AbiLHBTY (ORCPT <rfc822;foxyelen666@gmail.com> + 99 others); Wed, 7 Dec 2022 20:19:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229538AbiLHBTV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Dec 2022 20:19:21 -0500 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C6648DBEF; Wed, 7 Dec 2022 17:19:21 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id n9-20020a05600c3b8900b003d0944dba41so2376474wms.4; Wed, 07 Dec 2022 17:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=F7aBLr/WPCbhlzqY1hJmfvUDhrJb2eGJyyyPzfEuW20=; b=LO2BdsfLlTDkFnX9Xj5fkiZ3SWRLoLJZ0h95C8AfwUJ8qp1CuZbt9eE2I6UNsJx7kc +5ZGauRadHGOg2oxisS5UTc+xIO8QKzbRraYgBXReR6wTbFK0WYbTYhCga7c4Ngq6uXi sQxIZXMLCLFcigZhRa2g2bfmP4T+Z5drCbCexzMzcyRUjZVX403OYSO3LTJWPBfgAZcU 6klk5o/gTA8WUi5oDIHeiLWtWPWQqtLNfUB5H+fKXgwPbSYDAOYaHOo1ymbBjMUvN/JX n5hp2e59EPtTXimJFpZYfGsNxzOdQZVp6ebX4tlL3sG09xoul79SxjUE0Ho4XRh2/WCi faQg== 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:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=F7aBLr/WPCbhlzqY1hJmfvUDhrJb2eGJyyyPzfEuW20=; b=QKsNhRr5fijPhQIboM+4cHcwZHCOg6EtlXuWO8vM/dc2aLDGDd0zcYrg6xoyg40Atw Bddlhhw2pR/nzzS9zv1A//D52Mxf6PF/M67WnapIvuHdp1n2+KI8GAFbdE5nszTkh2Yn gPfhuuo0Hj5dtRhqJecKzERTju1VlYDtsjx/SOs5B8YM1oNkou4QnYdulyaSJ/AykSjq K5yz+IEAaq3uZzcF5MwLzRheBsDKUlgYuLkeDrEPElhrTVd7LTyaSeSz67z1oNWhoJAf aRobjwv/NAh9QJAfLNiiGbi/zbbDA68KHfjkPH50F72SuCa737k/+pNnBOccyEcID/o8 zl4A== X-Gm-Message-State: ANoB5pmH3wDVoW0mXXetXnOMAsuqXJcgxK/YusvWN+9h7PHUKuzFbwIH qtw+6CwOypWbcqXMuEs4CWq3RsM3RNO5ws0iOjzpm58UIAE= X-Received: by 2002:a05:600c:524c:b0:3d0:8698:4bcc with SMTP id fc12-20020a05600c524c00b003d086984bccmr17137435wmb.144.1670462359569; Wed, 07 Dec 2022 17:19:19 -0800 (PST) MIME-Version: 1.0 From: Hao Peng <flyingpenghao@gmail.com> Date: Thu, 8 Dec 2022 09:19:08 +0800 Message-ID: <CAPm50aJTh7optC=gBXfj+1HKVu+9U0165mYH0sjj3Jqgf8Aivg@mail.gmail.com> Subject: [PATCH] KVM: use unified srcu interface function To: pbonzini@redhat.com Cc: kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751606799773859604?= X-GMAIL-MSGID: =?utf-8?q?1751606799773859604?= |
Series |
KVM: use unified srcu interface function
|
|
Commit Message
Hao Peng
Dec. 8, 2022, 1:19 a.m. UTC
From: Peng Hao <flyingpeng@tencent.com> kvm->irq_routing is protected by kvm->irq_srcu. Signed-off-by: Peng Hao <flyingpeng@tencent.com> --- virt/kvm/irqchip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.27.0
Comments
On Thu, Dec 08, 2022, Hao Peng wrote: > From: Peng Hao <flyingpeng@tencent.com> > > kvm->irq_routing is protected by kvm->irq_srcu. > > Signed-off-by: Peng Hao <flyingpeng@tencent.com> > --- > virt/kvm/irqchip.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c > index 1e567d1f6d3d..90f54f04e37c 100644 > --- a/virt/kvm/irqchip.c > +++ b/virt/kvm/irqchip.c > @@ -216,7 +216,8 @@ int kvm_set_irq_routing(struct kvm *kvm, > } > > mutex_lock(&kvm->irq_lock); > - old = rcu_dereference_protected(kvm->irq_routing, 1); > + old = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu, > + lockdep_is_held(&kvm->irq_lock)); Readers of irq_routing are protected via kvm->irq_srcu, but this writer is never called with kvm->irq_srcu held. I do like the of replacing '1' with lockdep_is_held(&kvm->irq_lock) to document the protection, so what about just doing that? I.e. diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c index 1e567d1f6d3d..77a18b4dc103 100644 --- a/virt/kvm/irqchip.c +++ b/virt/kvm/irqchip.c @@ -216,7 +216,8 @@ int kvm_set_irq_routing(struct kvm *kvm, } mutex_lock(&kvm->irq_lock); - old = rcu_dereference_protected(kvm->irq_routing, 1); + old = rcu_dereference_protected(kvm->irq_routing, + lockdep_is_held(&kvm->irq_lock)); rcu_assign_pointer(kvm->irq_routing, new); kvm_irq_routing_update(kvm); kvm_arch_irq_routing_update(kvm); > rcu_assign_pointer(kvm->irq_routing, new); > kvm_irq_routing_update(kvm); > kvm_arch_irq_routing_update(kvm); > -- > 2.27.0
On Fri, Dec 9, 2022 at 9:22 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Dec 08, 2022, Hao Peng wrote: > > From: Peng Hao <flyingpeng@tencent.com> > > > > kvm->irq_routing is protected by kvm->irq_srcu. > > > > Signed-off-by: Peng Hao <flyingpeng@tencent.com> > > --- > > virt/kvm/irqchip.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c > > index 1e567d1f6d3d..90f54f04e37c 100644 > > --- a/virt/kvm/irqchip.c > > +++ b/virt/kvm/irqchip.c > > @@ -216,7 +216,8 @@ int kvm_set_irq_routing(struct kvm *kvm, > > } > > > > mutex_lock(&kvm->irq_lock); > > - old = rcu_dereference_protected(kvm->irq_routing, 1); > > + old = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu, > > + lockdep_is_held(&kvm->irq_lock)); > > Readers of irq_routing are protected via kvm->irq_srcu, but this writer is never > called with kvm->irq_srcu held. I do like the of replacing '1' with > lockdep_is_held(&kvm->irq_lock) to document the protection, so what about just > doing that? I.e. > Sorry for the long delay in replying. Although kvm->irq_srcu is not required to protect irq_routing here, this interface function srcu_dereference_check indicates that irq_routing is protected by kvm->irq_srcu in the kvm subsystem. Thanks. > diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c > index 1e567d1f6d3d..77a18b4dc103 100644 > --- a/virt/kvm/irqchip.c > +++ b/virt/kvm/irqchip.c > @@ -216,7 +216,8 @@ int kvm_set_irq_routing(struct kvm *kvm, > } > > mutex_lock(&kvm->irq_lock); > - old = rcu_dereference_protected(kvm->irq_routing, 1); > + old = rcu_dereference_protected(kvm->irq_routing, > + lockdep_is_held(&kvm->irq_lock)); > rcu_assign_pointer(kvm->irq_routing, new); > kvm_irq_routing_update(kvm); > kvm_arch_irq_routing_update(kvm); > > > > rcu_assign_pointer(kvm->irq_routing, new); > > kvm_irq_routing_update(kvm); > > kvm_arch_irq_routing_update(kvm); > > -- > > 2.27.0
On 12/20/22 08:47, Hao Peng wrote: >>> + old = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu, >>> + lockdep_is_held(&kvm->irq_lock)); >> Readers of irq_routing are protected via kvm->irq_srcu, but this writer is never >> called with kvm->irq_srcu held. I do like the of replacing '1' with >> lockdep_is_held(&kvm->irq_lock) to document the protection, so what about just >> doing that? I.e. >> > Sorry for the long delay in replying. Although kvm->irq_srcu is not required > to protect irq_routing here, this interface function srcu_dereference_check > indicates that irq_routing is protected by kvm->irq_srcu in the kvm subsystem. > Thanks. > I agree, the last two arguments basically are alternative conditions to satisfy the check: #define srcu_dereference_check(p, ssp, c) \ __rcu_dereference_check((p), __UNIQUE_ID(rcu), \ (c) || srcu_read_lock_held(ssp), __rcu) The idea is to share the code between readers and writers, so what do you think of adding a #define kvm_get_irq_routing(kvm) srcu_dereference_check(...) macro at the top of virt/kvm/irqchip.c? Thanks, Paolo
On Fri, Dec 23, 2022, Paolo Bonzini wrote: > On 12/20/22 08:47, Hao Peng wrote: > > > > + old = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu, > > > > + lockdep_is_held(&kvm->irq_lock)); > > > Readers of irq_routing are protected via kvm->irq_srcu, but this writer is never > > > called with kvm->irq_srcu held. I do like the of replacing '1' with > > > lockdep_is_held(&kvm->irq_lock) to document the protection, so what about just > > > doing that? I.e. > > > > > Sorry for the long delay in replying. Although kvm->irq_srcu is not required > > to protect irq_routing here, this interface function srcu_dereference_check > > indicates that irq_routing is protected by kvm->irq_srcu in the kvm subsystem. > > Thanks. > > > > I agree, the last two arguments basically are alternative conditions to > satisfy the check: > > #define srcu_dereference_check(p, ssp, c) \ > __rcu_dereference_check((p), __UNIQUE_ID(rcu), \ > (c) || srcu_read_lock_held(ssp), __rcu) > > The idea is to share the code between readers and writers, But readers and writers naturally don't share code, and the subsequent synchronize_srcu_expedited() is what really documents the interaction between readers and writers. It's definitely not a sticking point though, and this one does seems to be the outlier in KVM. > so what do you think of adding a > > #define kvm_get_irq_routing(kvm) srcu_dereference_check(...) > > macro at the top of virt/kvm/irqchip.c? I'm fine with any approach, though a macro seems like overkill.
diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c index 1e567d1f6d3d..90f54f04e37c 100644 --- a/virt/kvm/irqchip.c +++ b/virt/kvm/irqchip.c @@ -216,7 +216,8 @@ int kvm_set_irq_routing(struct kvm *kvm, } mutex_lock(&kvm->irq_lock); - old = rcu_dereference_protected(kvm->irq_routing, 1); + old = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu, + lockdep_is_held(&kvm->irq_lock)); rcu_assign_pointer(kvm->irq_routing, new); kvm_irq_routing_update(kvm); kvm_arch_irq_routing_update(kvm);