Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1968419ybj; Wed, 6 May 2020 08:23:34 -0700 (PDT) X-Google-Smtp-Source: APiQypKajoLvaYZdefrUGFAqyL46p0XrA6/xH7GhhnvdE8MjqBgjxScwJDu9pNfng5cVUapI7kNG X-Received: by 2002:a05:6402:1f6:: with SMTP id i22mr7684743edy.271.1588778613825; Wed, 06 May 2020 08:23:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588778613; cv=none; d=google.com; s=arc-20160816; b=xnQxv3WrT4RlYQXTLxTse8wilv6lng4qh4icHKwuAwlkkcwP5TSYUh7I5l35yGmygS quOMm4N8U8HpOOV6j3zeQE9sEsnbI4SCkfDaQ66f9shhYE+2SOXRmy3iQPpQI3h8vajT IZkKB14BvvaSxUdjt57xPAJKFLelXSTYMfHuiCtbJs2/LtvKMOC/i5NLr6Ws1q9IA2N3 scdZ/ozhLqN+Fy8MqqXmZv7f2YXof983BWu7CFiRxQUfVcxOzpVhBeRZtxkTqk7Sw3pJ ONk5cD5VShIZgAMIkTYHzDknBVLJS3MmyZLppoUWy1g0PxktxauP/KkcKtoxaTy2jKSf xDlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Fm4RReNAu2Cpk22Qx7H3mStZUQrd6w6yMNLS8On3NUE=; b=Ipfrt/wbFtC3Q4olL6x/GrhShSs2azUMnWYaOFO0Ou5XkmilEoOnNpgzNJaF8PUqZx Jku5alr6HNdVJ6ePXuvm7KjT2AwfZRsWS0AZbTZD8gY3Rwp39/KEnJMT1KjOGoiTDDNW VD5C5r/oYdbpY1KU0RUhn4OSMOSnoKN0xPo6upSHZUZ013yL7H4ppsS3vzJz+c80wg8F uJFWqomimEqCR9FacF9NJO0fIyR+ADvDo/CyzOV30RDFwdxbjtHlsM08tIkC94NqjmVU wDDbCGJxuqrOWKRxJnXTRtomqoCFOFIdGKKYC3COE83q735G2ZnQ8jwXw3nhchf3/x2d cxMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u3si1288825edo.526.2020.05.06.08.23.10; Wed, 06 May 2020 08:23:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729385AbgEFPVe (ORCPT + 99 others); Wed, 6 May 2020 11:21:34 -0400 Received: from foss.arm.com ([217.140.110.172]:38946 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729264AbgEFPVd (ORCPT ); Wed, 6 May 2020 11:21:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F2E2CD6E; Wed, 6 May 2020 08:21:32 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6BA333F68F; Wed, 6 May 2020 08:21:31 -0700 (PDT) Date: Wed, 6 May 2020 16:21:26 +0100 From: Lorenzo Pieralisi To: Michael Kelley Cc: Wei Hu , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , "wei.liu@kernel.org" , "robh@kernel.org" , "bhelgaas@google.com" , "linux-hyperv@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Dexuan Cui Subject: Re: [PATCH v2 1/2] PCI: hv: Fix the PCI HyperV probe failure path to release resource properly Message-ID: <20200506152126.GA2911@e121166-lin.cambridge.arm.com> References: <20200501053617.24689-1-weh@microsoft.com> <20200505150315.GA16228@e121166-lin.cambridge.arm.com> <20200506110930.GA31068@e121166-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 06, 2020 at 02:55:17PM +0000, Michael Kelley wrote: [...] > > Hv_pci_bus_exit() calls hv_send_resources_released() to release all child resources. > > These child resources were allocated in hv_send_resources_allocated(). > > Hv_send_resources_allocated() could fail in the middle, leaving some child resources > > allocated and rest not. Without adding this variable to record the highest slot number that > > resource has been successfully allocated, calling hv_send_resources_released() could > > cause spurious resource release requests being sent to hypervisor. > > > > This had been fine since hv_pci_bus_exit() was never called in error path before this patch > > was > > introduced. To add this call to clean the pci state in the error path, we need to know the > > starting > > point in child device that resource has not been allocated. Hence this variable > > is used in hv_send_resources_allocated() to record this point and in > > hv_send_resource_released() to start deallocating child resources. > > > > I can add to the commit log if you are fine with this explanation. > > > > FWIW, I think of this patch as follows: > > In some error cases in hv_pci_probe(), allocated resources are not > freed. Fix this by adding a field to keep track of the high water mark > for slots that have resources allocated to them. In case of an error, this > high water mark is used to know which slots have resources that > must be released. Since slots are numbered starting with zero, a > value of -1 indicates no slots have been allocated resources. There > may be unused slots in the range between slot 0 and the high > water mark slot, but these slots are already ignored by the existing code > in the allocate and release loops with the call to get_pcichild_wslot(). That's much clearer now - please add these bits of info to the commit log, it is essential that developers can find an explanation for a change like this one there IMO. Overall the code changes are fine, I am not a big fan of the (void) cast (I don't think error codes should be ignored) but it is acceptable, in this context. Thank you for taking some time to review the code together. Lorenzo