From nobody Sun Jun 14 23:04:17 2026 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (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 95CA13DEACF for ; Fri, 10 Apr 2026 18:32:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.128.181 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775845977; cv=pass; b=ePT65bSXizu64bHqzEUDZLhCrDwv95ZZELAXvxS8GsYn9CAoCGic7eVoatDkGEItzR+Dm88KhpH53TB7Fa0lUy3x4kCi6lKE3Ka2zQpwNXekdyW1wgWe+uIDCLtdQQbdzIHQCpjTBrd78EDk/zamsESBhQ5vMa19MJRQAEaoM7E= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775845977; c=relaxed/simple; bh=wuYI0RLFVZ45HYeDNdgJJ6D8GwLuqkaCkFsDbEpgJpg=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=iKuFGJneZh93s5iu+FV4WhQ3xZ8NhILjynWkOWRBgt/VRg7dmINBfCak6UVlh/I1cHpoi9jwMMLlE/10cEI3c9kW4qqHvQlodrQUf53j5i2sKq7CP5xn4eB5grMp0ZmSvGtCdtBL6vMRJV5wdQF6ofA2Y09obNJEvb2sgjFsWXE= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=openai.com; spf=pass smtp.mailfrom=openai.com; dkim=pass (1024-bit key) header.d=openai.com header.i=@openai.com header.b=MEz3EUGX; arc=pass smtp.client-ip=209.85.128.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=openai.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=openai.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=openai.com header.i=@openai.com header.b="MEz3EUGX" Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-7986e0553bdso24321467b3.2 for ; Fri, 10 Apr 2026 11:32:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775845975; cv=none; d=google.com; s=arc-20240605; b=AvCKDvK61Pp3GtM1XxZ2FbYlP87xablqo8D4Al8C3gqI1gonSz8AIwPNhdK5CWbKUk gx2T/+2ed9g0chAMu62ljL5j+Z7X9cQlBvybPRsMt77v0tQ44HHjwbDfyyUUIUoyBa6e Bb66k3md0UMRFMJKCbvoxf/S51pW77OSixAhBcYDfSOJuGVaYye8Q5keFPoIbM/b35Gy eR6jCyXWMO5jj/Y1bjZn9Rohh4D2RGfUiRTIk/wwZF47HlykVU5rtgjntyD2lHAdE9u4 q3R6fWvb4MacIAUkcVbS2tAKhJdOU8HwPagItAk3PYMZBnHiLzL2KbY1/URVn98z7gcH dEdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=ja5DFvBssG/HcQK4svdiTesOu+yaQKgasZ8owUN2Nvc=; fh=2hQTYm+62YkYc4miKhrnYZdPM+F86gCN9xi2u8ivWJU=; b=cvCkwwjHblezmSPc3Ugmyewxb78FAlTSyq5w5g2QVzSyjE5Qz4YxFSZVQUl81+TDsD wOziIUreor6ALa/vugqGLR7itmb7ErgxJUKgyArifSywnAotVA9DjuRG1cMaVdEJacdj aA/LZhr6Fqms138hj5skCDGc21cfV54VTxbgmDfcCFMjSEJqpTMbh99lc+yAAVz5It5V Skx9/va07t/FYmpRAQO7NTFwX3IV9L7Vs+xR16aGX5aFM4DjAPkzi7cq7RMlxzs4fWuR 1iZlfRFjhw10O5fN+nM5GuC5+1mrVErn0aGzvj05AzxhnUr3QRpc2ExQLUIPuNoR8hl2 Fj6A==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openai.com; s=google; t=1775845975; x=1776450775; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ja5DFvBssG/HcQK4svdiTesOu+yaQKgasZ8owUN2Nvc=; b=MEz3EUGXZLZgvyHCbAQ6WGTDHT05JSoT1WqX2qnKIhE3+BleIElU/2XGVlkEYPUT1w jv0d9tmUQHMhCPt6xjrxB3A/Uz1VjKb3iQSJIFi67Ln2tAXb9j254Fw0Lt8rdrSwbiBy aCUFAtmjZjf3X8+gSfEAy4S33ubvkUKFtAd8s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775845975; x=1776450775; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ja5DFvBssG/HcQK4svdiTesOu+yaQKgasZ8owUN2Nvc=; b=W0lHahMgGAzaxH6W5moTV3tgOlZU4W957nWgs4AuzzozEHxf2oTFY1FBnmVhSGUNdq YIuZ8jpytDE4jWME00n8VUue7ugNDzN97CbS6RstjbkW6uoew+EaPr0k3rlDJa1RTnCR S6i8nilL2J5a+ube2xkOPLpsqSAP3vh88ZBLCNmJ/57tefiLtOMv9/ZIKBhkc+5B518m sP4Pq8h8n5fLm96mHYr3XwtRM1S2eB5jJmoFBmAjMkqE9dvQGc98CgC2akxmuXkJAvpY acqZzE9wEJEwTTVETnnZgmGvZSK5CXdW43syRnCjSpv8ENdifVgfLgT0B9MSnmjyynQk ziYg== X-Forwarded-Encrypted: i=1; AJvYcCWDrU/yhor+iDYAlw+PVPSigyGnYEfP3joZZuh5RpmeIlY5OyBrM2BnPqy00TUvMXWinZfZ1D8WIuqhdiY=@vger.kernel.org X-Gm-Message-State: AOJu0YxWWIselsnSE4hnxhVuFpGK/D2ytaCcpRAg9FW1jaW+OgRJxieR MiLbljnPfMMo+8YD9j5FT6uiyodLLD4sLD22YT/MMmx3DZZCbDt57wec9l5PDOi77FArkiqcdeW Xn44Cevf3EmQOW659gjIrAeG20kVABhESlty3tR1xvQ== X-Gm-Gg: AeBDiet07ml2/jtsjInpr3wbrjrGbmzUNHK6ZvKMXx1LA0md7Mo7uVsxDalJ3gmXxaz Xnkggrq1Vpx1lrDktJxSJGU136w9acN+6H+KVlAavsxG47sqL2+CC5PfM7GlTiE47HCcO15I7Ov LnVqwkK6Ppi2KfrFPZuFhOyvHUlXuc7tAdHDx4fPdUKeD/3NhbWoNBW3hVAWmN8K7W4gk8KfGxe MXh5lclm4vF+M/TjtbvEE5CZr/dC+Q6qWGzFrwY1j3O0YhfmVAYRrc0bdmeznPksbgaNzVIC2ZW ynl74LjjeXU6Mroc2k9JVVUUpbFT6dX84pdIa4QJxRODwnWbtfoy8mT/iEG60fqe4IurkyFeJnh QEHBwFXMJoG/pQnXeINKnRDo2fVy/pxwSi5Q0AlpPEdLDePozjyXOBgu6wOL+Xkc= X-Received: by 2002:a05:690c:386:b0:79a:c396:bfd with SMTP id 00721157ae682-7af7282e484mr46611397b3.53.1775845975495; Fri, 10 Apr 2026 11:32:55 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Sina Hassani Date: Fri, 10 Apr 2026 11:32:44 -0700 X-Gm-Features: AQROBzC0kt-YXtizzhgXbBbxbP2jPMd7-xT0-_zTfAyjyTIg0aNxYbMeqSKenFY Message-ID: Subject: [PATCH v4] Fixes a race in iopt_unmap_iova_range To: Jason Gunthorpe Cc: kevin.tian@intel.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Aaron Wisner , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Bug: iopt_unmap_iova_range releases the lock on iova_rwsem inside the loop body when getting to the more expensive unmap operations. This is fine on its own except the loop condition is based on the first area that matches the unmap address range. If a concurrent call to map picks an area that was unmapped in the previous iterations, this loop will try to mistakenly unmap them. How to reproduce: I was able to reproduce this by having one userspace thread mapping buffers and passing them to another thread that unmaps them. The problem easily shows up as ebusy errors if you use single page mappings. The fix: A simple fix that I implemented here is to advance the start pointer after we unmap an area. That way we are only looking at the IOVA range that is mapped and hence guaranteed to not have any overlaps in each iteration. Test: I tested this against the repro mentioned above and it works fine. Cc: stable@vger.kernel.org Signed-off-by: Sina Hassani --- drivers/iommu/iommufd/io_pagetable.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/iommufd/io_pagetable.c b/drivers/iommu/iommufd/io_pagetable.c index ee003bb2f647..355f7227305a 100644 --- a/drivers/iommu/iommufd/io_pagetable.c +++ b/drivers/iommu/iommufd/io_pagetable.c @@ -814,6 +814,12 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, unmapped_bytes +=3D area_last - area_first + 1; down_write(&iopt->iova_rwsem); + + /* Do not reconsider things already unmapped in case of + * concurrent allocation */ + if (area_last >=3D last) + break; + start =3D area_last + 1; } out_unlock_iova: -- 2.43.0