From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58DF0653 for ; Mon, 19 Feb 2024 06:47:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708325237; cv=none; b=OnUI5tj21kKHB2rreoQsDnlhV7XeMje5bzoDrTz62F18VLuE25OY1YZIrJ291znsbSskF0gEnSZX0QO1TXaOHdLjY30mvLZgbQzNvRW//szu6ICqTlr3F5fNI3TyJEHAiG6Z38gjSYctuLHKbTGlEllLm4muntsBns2L6MWVzsE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708325237; c=relaxed/simple; bh=AQgWjzvqTiOHr11WQ/mBCiNAoANxgSSG+XlUuNZd+yM=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=A3KsRRa2k+jEIo+L69a4fV0h2xpsyDLldBTTM+R60Ql7ZbBCBvI0fmatcv15/DO9WaTMtz087ehoGu6SVNhEoFZNH2Efq94Dv4zchwgYHYyjzc0LUCTrVQCQqiw/InjGdCUBLVSrhsXkx8b6D5sHnl+TZSt9piw1/6BddOMFtNs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nSXFxpCA; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nSXFxpCA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708325234; x=1739861234; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=AQgWjzvqTiOHr11WQ/mBCiNAoANxgSSG+XlUuNZd+yM=; b=nSXFxpCADiF7HbP0jfhVf/7f7RYOHnEGruHEwb5kuE+lRO0tvUsMY10W S+TRsOKjvQih61KEUC+fkPaxl5Qenv71a+cOTqi9uYs3zIWesqJu1zSz8 qGd2pi4wE6Ij5yApX1KD2YyAR0Zp2bV6LbHn4+FHshVgCtHlyjFutfWYu 1glfpvpRMrswHPlq4MbqZGhogdDX2+SdJBkZDapU0UPpUkp+gjsn/Igry 9fat9149qQH6pWdw8kWGDtxYrqMj+8t+NOL9bWuzY/M7Vg5k6m3Mu7SvN iPMYEbds1DkvgSfbVjukIVMYjwXdcxhwe8DvLXE2ZSzRCjPPGXnmPuWpf Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10988"; a="2253336" X-IronPort-AV: E=Sophos;i="6.06,170,1705392000"; d="scan'208";a="2253336" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2024 22:47:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,170,1705392000"; d="scan'208";a="4659757" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.254.215.112]) ([10.254.215.112]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2024 22:47:11 -0800 Message-ID: <11a2a48f-aad9-42b0-a9a1-29ea1c0f7f45@linux.intel.com> Date: Mon, 19 Feb 2024 14:47:09 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, Huang Jiaqing , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] iommu/vt-d: Use rbtree to track iommu probed devices To: Ethan Zhao , Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian References: <20240215072249.4465-1-baolu.lu@linux.intel.com> <20240215072249.4465-2-baolu.lu@linux.intel.com> <942dd645-7475-4c43-99c6-304601fb09eb@linux.intel.com> Content-Language: en-US From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024/2/19 13:33, Ethan Zhao wrote: > On 2/19/2024 12:04 PM, Baolu Lu wrote: >> On 2024/2/19 10:45, Ethan Zhao wrote: >>>> @@ -4264,25 +4313,34 @@ static struct iommu_device >>>> *intel_iommu_probe_device(struct device *dev) >>>>       } >>>>       dev_iommu_priv_set(dev, info); >>>> +    ret = device_rbtree_insert(iommu, info); >>>> +    if (ret) >>>> +        goto free; >>>>       if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) { >>>>           ret = intel_pasid_alloc_table(dev); >>>>           if (ret) { >>>>               dev_err(dev, "PASID table allocation failed\n"); >>>> -            kfree(info); >>>> -            return ERR_PTR(ret); >>>> +            goto clear_rbtree; >>>>           } >>>>       } >>>>       intel_iommu_debugfs_create_dev(info); >>>>       return &iommu->iommu; >>>> +clear_rbtree: >>>> +    device_rbtree_remove(info); >>>> +free: >>>> +    kfree(info); >>>> + >>>> +    return ERR_PTR(ret); >>>>   } >>>>   static void intel_iommu_release_device(struct device *dev) >>>>   { >>>>       struct device_domain_info *info = dev_iommu_priv_get(dev); >>>> +    device_rbtree_remove(info); >>> >>> Perhpas too early here to remove dev from the rbtree, if it is wanted in >>> devTLB invalidation steps in intel_pasid_tear_down_entry(). >> >> Perhaps the caller of device_rbtree_find() should not depend on the > > I didn't catch up here. seems have to maintain the lifecycle as PCI > subsystem > does, or there would be mutli instances for the same BDF(e.g. the device is > removed then plugged, again and again.....in the same slot) in the rbtree ? There should not be multiple instances for a same BDF. The lifecycle of a device is managed by the device and driver core. The iommu subsystem registers a notification to the core and take actions on device ADD and REMOVE events. Best regards, baolu