Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2590420pxb; Sun, 3 Apr 2022 12:40:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2yHVn9jjjGVxvxOYI8mBib+FJhydwhe22iD0e6mkfMkbGfqx27fg4WtESlrheh+V+e2mo X-Received: by 2002:a17:90b:4d88:b0:1ca:a5c5:1386 with SMTP id oj8-20020a17090b4d8800b001caa5c51386mr331033pjb.43.1649014846463; Sun, 03 Apr 2022 12:40:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649014846; cv=none; d=google.com; s=arc-20160816; b=OS15Y/h/V3LiZD4VgZldqdIAl1wVLtGvye/wLBpUUkTrD61hW3mLEGWHGbxYVaXhrf xLAqOPeuQadrP89na4aPCOMp2FBvwDk30HmuK4iA+rH9jxIHN2TVdZqo8ePMvnjjIn9h G0ich77RaebG4ZLsdPTNsZ6AvsqauD8uVJ1dz4OgNQPwXwftbAaOUno5zWzbG6tQsGQU k0tknaRo3/MSLsdvHzJibvkLFupfF2zI/YvLO3kk8yktdx5lwvpSZK0J/xQ5nLqcj/XM n/EP8mHZxla/VuDNDUDf4UrBFXDx5Rtj2qVzsfSBiljHNbUNoxmI0dN8mfbn4Qywntg7 Jvug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=4pIkLo492sJgn0Tf5PhOvHnbsFGJpe4T4zxP4i8IhZ8=; b=r0edTS0hXa5avU3r+EAG72i+Py2fP2525HXNfy9618aE82tDsI1hQdKilW15424CYf AfJcQZ5EFzGmUGmpVa8XZt9tIPqMdir144sqRzZqxVQZPTsVD81fFkMuicekzAJkHM+a nkQoDaBDfmrDTORKXJTFAfnEVS4XhO24L5xvVuLsvnvvGNvI7mRYZjDzzFhf+XXJIWWM m1oOsP99a7fu+ksk7nB2MmZ7lN62DpVhZu4bDNo6C+uHvvUTx1RAVB7EWfZA7IJGl7oN j5gmYLgHcPTpnvOhAhVw99uq/ylJ91XKVQLB5TNh5LWqqdiHQd4k0KM3JMuRXLxhMvQw PZIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eJ7zC+eu; 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 c23-20020a17090aa61700b001caa29ceeb4si548098pjq.169.2022.04.03.12.40.32; Sun, 03 Apr 2022 12:40:46 -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=eJ7zC+eu; 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 S1347384AbiDAQrA (ORCPT + 99 others); Fri, 1 Apr 2022 12:47:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349519AbiDAQqu (ORCPT ); Fri, 1 Apr 2022 12:46:50 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFC87170084; Fri, 1 Apr 2022 09:30:19 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id bh17so6945606ejb.8; Fri, 01 Apr 2022 09:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4pIkLo492sJgn0Tf5PhOvHnbsFGJpe4T4zxP4i8IhZ8=; b=eJ7zC+euchPUgDMoXaWTQCW7vfXQStXEn1D8Dq4IVZcxPuYjYzt0EBr649lpuwLDhw i176K1V1oqZfdTdS2tNQm4ICUc+vrLusSPSI4b2/mwtv6AIsB/Damt8/C/nZdWmbEAbh R6aQj1xI8iejSzxLOeRPxrGMGOQPb8IRrD+3ASkMuDGqGro9g972js4U8jq5KGpoMHNk ENikHv3l5mskWlqd3E4c7cuQ0t2GB+VhGQgeC0cqv19Yo66ZQeaf246o5AwDiem9Y+mc D1v1/H7CgrQqx3Be7xJMLCeTLpCfaAJOfmbHheaXXhTVCwEsCGI7kSferCQqoT8zLi34 lGoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4pIkLo492sJgn0Tf5PhOvHnbsFGJpe4T4zxP4i8IhZ8=; b=ZdZqoLV0AwqdxAqjmXqfzq3m85d9+76TAAazUKopwN19yjFTiX9gADlR1aisSxiL/n AdKUP040R3HI3xlyG8cpMlnAsZsdoE/IyAuizR01uy7TsiNFz668jYgFMWltoHwoxl6Y N441R443Jdz1vQMlglsO3Hu+FnguzNkI2xJwuY6y8ezhJhvMam6S3mF5Bt8CafBgk5ty cqA5pAnZFNr+3IcOS5Yjw8z2ssJl7b1P9iq0foWFXw9SL2i9eBRE7mQEIsMnyJITKKIq LAfKbtJg+DaNh0L4oPuX+kzD3ypKAXKl6N9C89uyu+Bwcr30nPo3P7LFC87TY7SUDcc+ DGag== X-Gm-Message-State: AOAM5337RGEdy6YAvim8wRj8zmjhXwwczc2dwrWCOKpD3Ivxc/yAha4F JhO1quxdDU0r/4PhrL647/Y= X-Received: by 2002:a17:907:97cc:b0:6df:83bc:314c with SMTP id js12-20020a17090797cc00b006df83bc314cmr515522ejc.587.1648830618325; Fri, 01 Apr 2022 09:30:18 -0700 (PDT) Received: from anparri (host-82-59-4-232.retail.telecomitalia.it. [82.59.4.232]) by smtp.gmail.com with ESMTPSA id o8-20020a17090611c800b006e4de0c89bbsm607804eja.198.2022.04.01.09.30.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Apr 2022 09:30:17 -0700 (PDT) Date: Fri, 1 Apr 2022 18:30:15 +0200 From: Andrea Parri To: "Michael Kelley (LINUX)" Cc: KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Wei Hu , Lorenzo Pieralisi , Rob Herring , Krzysztof Wilczynski , Bjorn Helgaas , "linux-hyperv@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 4/4] PCI: hv: Fix synchronization between channel callback and hv_compose_msi_msg() Message-ID: <20220401163015.GC437893@anparri> References: <20220328144244.100228-1-parri.andrea@gmail.com> <20220328144244.100228-5-parri.andrea@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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,T_SCC_BODY_TEXT_LINE 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 > > @@ -1662,6 +1662,55 @@ static u32 hv_compose_msi_req_v3( > > return sizeof(*int_pkt); > > } > > > > +/* As in vmbus_request_addr() but without the requestor lock */ > > +static u64 __hv_pci_request_addr(struct vmbus_channel *channel, u64 trans_id) > > +{ > > + struct vmbus_requestor *rqstor = &channel->requestor; > > + u64 req_addr; > > + > > + if (trans_id >= rqstor->size || > > + !test_bit(trans_id, rqstor->req_bitmap)) > > + return VMBUS_RQST_ERROR; > > + > > + req_addr = rqstor->req_arr[trans_id]; > > + rqstor->req_arr[trans_id] = rqstor->next_request_id; > > + rqstor->next_request_id = trans_id; > > + > > + bitmap_clear(rqstor->req_bitmap, trans_id, 1); > > + > > + return req_addr; > > +} > > + > > +/* > > + * Clear/remove @trans_id from @channel's requestor, provided the memory > > + * address stored at @trans_id equals @rqst_addr. > > + */ > > +static void hv_pci_request_addr_match(struct vmbus_channel *channel, > > + u64 trans_id, u64 rqst_addr) > > +{ > > + struct vmbus_requestor *rqstor = &channel->requestor; > > + unsigned long flags; > > + u64 req_addr; > > + > > + spin_lock_irqsave(&rqstor->req_lock, flags); > > + > > + if (trans_id >= rqstor->size || > > + !test_bit(trans_id, rqstor->req_bitmap)) { > > + spin_unlock_irqrestore(&rqstor->req_lock, flags); > > + return; > > + } > > + > > + req_addr = rqstor->req_arr[trans_id]; > > + if (req_addr == rqst_addr) { > > + rqstor->req_arr[trans_id] = rqstor->next_request_id; > > + rqstor->next_request_id = trans_id; > > + > > + bitmap_clear(rqstor->req_bitmap, trans_id, 1); > > + } > > + > > + spin_unlock_irqrestore(&rqstor->req_lock, flags); > > +} > > + > > Even though these two new functions are used only in the Hyper-V > vPCI driver, it seems like they should go in drivers/hv/channel.c > along with vmbus_next_request_id() and vmbus_request_addr(). > And maybe vmbus_request_addr(), which gets the spin lock, > could be implemented to call the new version above that > assumes the spin lock is already held. Also, the new function > that requires matching on the rqst_addr might also be folded > into common code via an optional rqst_addr argument. Noted. > > @@ -2747,17 +2808,27 @@ static void hv_pci_onchannelcallback(void *context) > > switch (desc->type) { > > case VM_PKT_COMP: > > > > - req_addr = chan->request_addr_callback(chan, req_id); > > + spin_lock_irqsave(&rqstor->req_lock, flags); > > Obtaining the lock (and releasing it below) might be better abstracted into > a lock_requestor() and unlock_requestor() pair that are implemented in > drivers/hv/channel.c along with the other related functions. Seems like these helpers should go 'inline' in , let me do it... Thanks, Andrea