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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE2ADC4332F for ; Tue, 12 Dec 2023 15:18:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376627AbjLLPSG (ORCPT ); Tue, 12 Dec 2023 10:18:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376469AbjLLPSF (ORCPT ); Tue, 12 Dec 2023 10:18:05 -0500 Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B2A7AA for ; Tue, 12 Dec 2023 07:18:11 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-77f3c4914e5so310170285a.3 for ; Tue, 12 Dec 2023 07:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1702394290; x=1702999090; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/fUIa9V7UktxZJFMOjKnGCbu4VLxyvHPNj4gCPjpKbw=; b=dbZCWhMdelQt22bjfK5pmXaNXkzjATMkBRQRgAymNXmWujrCV26O56Tbrkho8v/hHm +UvT0vg00L/E+5+tiKwCIM68hDT5un4m6E/RDxYtINwSiXqYtGf7jm4vFOd/PUYe+lXX 5WY8dKgzGaiJ3zy7/7N+IwEMzSPD0pLaa9NatW+JuAjOyG6L3osoQgzA8MDQK06F9yoj 9lpnBHiSkP08SWNPvuBIkFnYXHb8cTNmF6CTyiKh/+Pnsbeln7tYcgIHgtufxo4up0ev rXb8oTu02eO2qS68oEgwitsE5/Txj7Vew/1HaqYVT2sBaSFpJHN+YtVupagf5XL2GAiq Dxlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702394290; x=1702999090; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/fUIa9V7UktxZJFMOjKnGCbu4VLxyvHPNj4gCPjpKbw=; b=fWt5pSsyGdIZgc4UM3iMcMgSZfLfdyhdIpskepCrereVH8T0RGHBDtx4feNigV8upb 7LDAlDGF4dep8IB7X7kdAyzRuxcKWpa2GIhgdzFxh93Px58mzrk4+p7eyfyJG0Syfkjs zWCb3ZpJ8ZQdcru7zrfhzpSSg/3fLmy/vxnCG5Oxfbb94j1x00JhTSABIuJOrvHbEeP+ 9za4GALcyBIdkyuri0pIVDNdoPSFsYwX+T7rWeBO4mDxvx7T1j2BH2MZWLeb7h4mXLtk sXWn35ZIHog19ly4968YVvLzTkzct6PrtPN4L3Rxd3auD1pN68mHEzcANwPz7Cpqbj6L 9i1g== X-Gm-Message-State: AOJu0Ywun+RUplt3EJgO7OVxqDO8/0GrW4dn09n/+mSL0d/zeS8lgSof Mhqssq1gfeJ2O9iSRXAe65gq/w== X-Google-Smtp-Source: AGHT+IEO/Sp55UvFmU80+iPDIwa6VlDwgsHYJtE8bskomQaUuOkqvskk69ktoa1wViJw6YFWts4t4A== X-Received: by 2002:a0c:d644:0:b0:67a:bc4f:341f with SMTP id e4-20020a0cd644000000b0067abc4f341fmr7016622qvj.83.1702394290678; Tue, 12 Dec 2023 07:18:10 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-134-23-187.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.134.23.187]) by smtp.gmail.com with ESMTPSA id c13-20020a056214004d00b0067a4f49a13csm4048421qvr.127.2023.12.12.07.18.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 07:18:10 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1rD4WP-00Ck2Y-Mq; Tue, 12 Dec 2023 11:18:09 -0400 Date: Tue, 12 Dec 2023 11:18:09 -0400 From: Jason Gunthorpe To: Baolu Lu Cc: Joerg Roedel , Will Deacon , Robin Murphy , Kevin Tian , Jean-Philippe Brucker , Nicolin Chen , Yi Liu , Jacob Pan , Longfang Liu , Yan Zhao , iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 12/12] iommu: Use refcount for fault data access Message-ID: <20231212151809.GD3013885@ziepe.ca> References: <20231207064308.313316-1-baolu.lu@linux.intel.com> <20231207064308.313316-13-baolu.lu@linux.intel.com> <20231211152456.GB1489931@ziepe.ca> <0f23e37a-5ace-492c-82e9-cf3d13f4ef6f@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f23e37a-5ace-492c-82e9-cf3d13f4ef6f@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 12, 2023 at 01:07:17PM +0800, Baolu Lu wrote: > Yes, agreed. The iopf_fault_param should be passed in together with the > iopf_group. The reference count should be released in the > iopf_free_group(). These two helps could look like below: > > int iommu_page_response(struct iopf_group *group, > struct iommu_page_response *msg) > { > bool needs_pasid; > int ret = -EINVAL; > struct iopf_fault *evt; > struct iommu_fault_page_request *prm; > struct device *dev = group->fault_param->dev; > const struct iommu_ops *ops = dev_iommu_ops(dev); > bool has_pasid = msg->flags & IOMMU_PAGE_RESP_PASID_VALID; > struct iommu_fault_param *fault_param = group->fault_param; > > if (!ops->page_response) > return -ENODEV; We should never get here if this is the case, prevent the device from being added in the first place > /* Only send response if there is a fault report pending */ > mutex_lock(&fault_param->lock); > if (list_empty(&fault_param->faults)) { > dev_warn_ratelimited(dev, "no pending PRQ, drop response\n"); > goto done_unlock; > } > /* > * Check if we have a matching page request pending to respond, > * otherwise return -EINVAL > */ > list_for_each_entry(evt, &fault_param->faults, list) { > prm = &evt->fault.prm; > if (prm->grpid != msg->grpid) > continue; > > /* > * If the PASID is required, the corresponding request is > * matched using the group ID, the PASID valid bit and the PASID > * value. Otherwise only the group ID matches request and > * response. > */ > needs_pasid = prm->flags & IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID; > if (needs_pasid && (!has_pasid || msg->pasid != prm->pasid)) > continue; > > if (!needs_pasid && has_pasid) { > /* No big deal, just clear it. */ > msg->flags &= ~IOMMU_PAGE_RESP_PASID_VALID; > msg->pasid = 0; > } > > ret = ops->page_response(dev, evt, msg); > list_del(&evt->list); > kfree(evt); > break; > } > > done_unlock: > mutex_unlock(&fault_param->lock); I would have expected the group to free'd here? But regardless this looks like a good direction Jason