From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F59933262A for ; Thu, 16 Jul 2026 15:44:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784216684; cv=none; b=IEA8h/KbtoIliWySdgP4+WQhFGLemh5eZg3sxigH6SKAHBio6zBI5HsB7E1DU7eyEtCoExMqFqSRYuRQbSZBeQvyRS4pqR4onUumut4IKyEwDiWJXezTFeqLY/8wbYmN6bMUsIiyepvkCnBYpSnbfHdHCTSRepfbDb7s2LBFk+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784216684; c=relaxed/simple; bh=MBNT4RmlhDZXOrdqScjFaMpobET3nW3VaZ0iff2/mQs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lspJvpJ0QPp3dTzz1kPvftnH70aQ4XnrQUoYWg+ktWU1qEvAj3j/3dVnoiyUIMBUamEnF0HFOM+01W98+h2S1LP7AB9pmEZFW0g2Drmj7WtXu0k5K4jIHQNTehzTHnO29jD8OtsZalAQKG2osVMtalR7uRxJs+CHwhd6YL3+l5o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=G0EwUBrX; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="G0EwUBrX" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2cab97c86bdso18965ad.1 for ; Thu, 16 Jul 2026 08:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784216683; x=1784821483; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=RZnPgAsegwq5RNUmT4pZ5ZYEwWcgYfPlPFNTQ6BdGMM=; b=G0EwUBrXspczOjod1PhU/M3BeT9h05HRPaMp5klNER1NNAIM5V8uqP7Ji3ZPHQtP5i M1ttv9cNXxYYeZ+eKPmXl+MA216tRAyw1QkgV4XuUI62dEiDktmwvihEejIEPwJhGceE 0Yvg2olkUdyDh37TDb8tISwyhR5BZdTMvz9QHreID6MpjqeWPIqi58mDKz7VYfsAa0Eo gs8AMXA5F7cSPEPcU9cF/BTD/nJKILlr/W1JDj9O9FI7TlwWb5C0QYLDZM1SBhuDCTmV KmgtFf5LJIG2a1PZv0z3eZhFvbs/bTH6ZcpFpNurr7KhBXOSMxgNbdOc8xBrUQih20fe zBww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784216683; x=1784821483; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=RZnPgAsegwq5RNUmT4pZ5ZYEwWcgYfPlPFNTQ6BdGMM=; b=rZ7xZ76RdekBWgVO2D/RdrdAp3J/NLfygMvQ86SUUSoVKjRJELHb2KCvu0SoSxVPNf hlJOSGKYhZT/uoKImKWSPrSaBE4v2L6o1Kugw2Xt4FDOzeRN1JyFf25+S6gK5TW//Ukl 0GYS2Q4AJ4XDu697/5Sl3vRABRqa3nCo1qFLQrCwOXDhZ2ZydfHOuY1+PJ2L5OAu0F7A 8T4WC2pi9RiRI8efXudo71QoPxhaFoYwiOic2dKTZ1AQ2xf8sddEmSmjJoKhpcY0WBFp SMJCeCC5i1WzXGCyleKINSWc+SvlcruTxA7/rFGwUwL7CD+bNNoSVVP1twFwW9aMM85L assw== X-Forwarded-Encrypted: i=1; AHgh+Rpagl8V9fRBFZnpMJWObZ8yW5+rxwn4vhIxZHA64lG0MNmXtttJ+9YBlBNMwrMAPUv41MV2tzO0KvwTtMc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5AOMeT9UqInclkYaTsuRQyljqexsSygc8oUSbEziO1cZN95yK tQg0grq7ipC9KLajPe58/iD7087fjv60ghss7LzzAoYGdNHd2VGGD5DOG1690JfOUg== X-Gm-Gg: AfdE7ck1JSpw6W6XzvPK3UXmbF4hLYfaYYKcgclQDujs1xc4kcSUNdp+sMxjZTnsoVk qq8hL1SJUU5TgerKgDX7dDN2XYluyl4yXFjwzRuJoDJEXB+TRAZE6issVTxu6SOxau9Q2SjfqcH iYxzbetkjWTDefdkuhS5MaCul1nvDTyOOmXIDIw8FgdIv4yDIWDwJZ9CfJCC6rAP3shiQpJCde0 uBgB6HCuw1QEQeXYvcP7maSryaPA6rZZsDhNzryyn8vF2eOK9+R+qWoLedV7hHg8fEW+1M8Qpza voPMP5dGY98dX9HyUaaDsxi9dmNugGEeZbzlVcwi03RqRrvQyXSM2wtwmbpptjxP4s+qOn0dXdQ 3Dxwual1olNoIKJsgZd9osGo3Yo3ZrOSVz3nBpzG1nEmjiECyIAiAFwmYStTHXLCIAJkwhiO7FO ydu/d+AuJ8vQJgiycZm5yBTaqlDGpkpSSJIO4XJEiKC6woVcukqYWqPpwFeOs8HXAJMungnvgD X-Received: by 2002:a17:903:440c:b0:2ca:e0db:3cc with SMTP id d9443c01a7336-2cf1dafe691mr2849285ad.11.1784216682206; Thu, 16 Jul 2026 08:44:42 -0700 (PDT) Received: from google.com (168.136.83.34.bc.googleusercontent.com. [34.83.136.168]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84a532eab84sm4717586b3a.0.2026.07.16.08.44.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2026 08:44:41 -0700 (PDT) Date: Thu, 16 Jul 2026 15:44:38 +0000 From: Samiullah Khawaja To: Baolu Lu Cc: David Woodhouse , Joerg Roedel , Will Deacon , Jason Gunthorpe , Robin Murphy , Kevin Tian , Alex Williamson , Shuah Khan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Pratyush Yadav , Pasha Tatashin , David Matlack , Andrew Morton , Pranjal Shrivastava , Vipin Sharma Subject: Re: [PATCH v3 07/18] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Message-ID: References: <20260614233728.2212104-1-skhawaja@google.com> <20260614233728.2212104-8-skhawaja@google.com> <847f0e2e-abfa-4d6b-98a5-5e25ffe66d8f@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <847f0e2e-abfa-4d6b-98a5-5e25ffe66d8f@linux.intel.com> On Sun, Jul 12, 2026 at 03:35:39PM +0800, Baolu Lu wrote: >On 6/23/2026 3:19 AM, Samiullah Khawaja wrote: >> >>>>+ >>>>+static void unpreserve_context_table(struct intel_iommu *iommu, >>>>+                     struct iommu_hw_ser *ser, >>>>+                     u8 bus, u8 devfn) >>>>+{ >>>>+    struct context_entry *context; >>>>+ >>>>+    spin_lock(&iommu->lock); >>>>+    context = iommu_context_addr(iommu, bus, devfn, 0); >>>>+    spin_unlock(&iommu->lock); >>> >>>The spinlock is dropped immediately after reading the address pointer. >>>If this is guaranteed to be safe, please add a comment to explain why a >>>UAF or race is avoided here. Otherwise, the locking scope needs to be >>>extened to protect both the pointer lookup and use. >> >>In the Intel VT-d driver, context tables are never freed once they are >>allocated during runtime, as they can be shared across multiple devices. >>So I took the lock here to protect against concurrent allocations inside >>iommu_context_addr(). Once the address is read, it is safe to use >>without holding the lock until the DMAR unit itself is torn down. >> >>I will add a comment explaining this here. > >As part of this series, I think this is acceptable. However, there >is room for further improvement in iommu_context_addr(). We could avoid >concurrent allocations by replacing the code below with try_cmpxchg64(): > > phy_addr = virt_to_phys((void *)context); > *entry = phy_addr | 1; This sounds great. > >At the same time, we could also replace the spinlock with an rwsem to >eliminate the spinlock critical section. Consequently, the GFP_ATOMIC >allocation in iommu_alloc_pages_node_sz() could then be replaced with a >normal GFP_KERNEL. +1 to this also. > >Thanks, >baolu Thanks, Sami