From nobody Mon Jun 15 11:09:08 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 2AAC03876B3 for ; Thu, 9 Apr 2026 22:10:32 +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=1775772637; cv=pass; b=ftKrPoqrkNgxYzkOj5cOyWML7khftESd06SwrG10Ou/74/0w2prFRbawmyHnj1OWHfscV+HLCPR5MTPRbOQ+vRNywTPIykkgyPd+Dkazp50KhN0qiaHI8LRmCE+aNz8e/hO5x6MvnQH6L/QaotbBSd1CGYj/GyE9s6EfKdJZuLE= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775772637; c=relaxed/simple; bh=u6Edix2jXuIS8tFnaNTmah71uMoOsikDpNEPIIstLWo=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=pYa/VExMS3tD7UGEj46w7eyFFoyo930yIF6ai/xUztkviBEvN/qiH5GqO/94D50a/R1rUm0TX0IWKN9P5SMVubi5tWqaoJzMGTAtoBORx1tEFWdeSjU2R7eWNPPjW8/NT6W6mdEGmE0lWguSPkJpqhRlXXbqTA5U7LAir2o5yK8= 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=GhlvTmVE; 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="GhlvTmVE" Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-7982c3b7da9so13268507b3.1 for ; Thu, 09 Apr 2026 15:10:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775772631; cv=none; d=google.com; s=arc-20240605; b=KYbJLxfMP9fuN33rau9ebfsnn7oTmGoM3GdzZpJJ/+ZFT8XKVb2bwEdwsF1if3Klt2 vOG57jgM08BXq64TSsZ+D50lZdzsPMt47G4tX+PmJgBDTmGOUbncNfwxE7DrxVHmDIzg BhrAcQdqa9IDfBkm4AvT7Y5k4SKf2GO5AW17cNe3IYsRc5Z+K2BZihUiAN9D7NwlkE8G zZEFsNGm0KmESn3soo4zvpEj+3Gee6OpPWlgeT9Wde0ynagVnbvtinDbO8Nj7GepZaYx zqKVlnUcoAQBhVnBeu1BqWxqi+o5ZemoGCZPNLn+PpcJtQJ4PJXmHlyfiGHbEoOwBDSD UwXg== 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=9OYRv8rvi0/sGy/tiETryCkJVCR2waOffWO1EsBR59E=; fh=v5ghX/tfr7K9vn6YuxjzkmDRtQefh+sQQ+aTSkirDsI=; b=lAZZHx8YhpkLQDnHrnWyeKEZXqGTxRyh4dnZwCQuTiZLOLvaGSnQ+ydGgcrQp7E8WV ISaz0n5cRfD7efcEaDrxA9WKE1KDVWiTSCGLh/lMY3SQKYqGOwpPij16ta2E2XRyhqqc ZaXLN7kVbsdVDocCIAGnUpFmg+CLbvnrr7SAsMGuBWxyYafwHthQHfV/XPr+AdYXhwH+ FvWWeS+e5AtUhXCtMQmt0GgN7KN3hyArOyKAOB43z2TuWBGb6QiODiI1PMCZmB+zJJP8 u/Gdleu/Yev2gf9wAZMjcNJaUyXL12Kpl5MlTxzl6WaOQh10d11DbpW2u5+I1HTYMRE4 j98w==; 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=1775772631; x=1776377431; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9OYRv8rvi0/sGy/tiETryCkJVCR2waOffWO1EsBR59E=; b=GhlvTmVEAj2WRkDBStv/w89BVOlPRS7k9cp/nP6BchnwC+XdsxXNqRfK8p8EkUh7J1 /GOjuhAxzcJmlcfG7WGBoCKuQuTDv79AY+QVD0QhuWwd4bywHPdZzgBFK3WFf7yGaHzI WpBcR6HhVO+s1JzyP/SDPygBfmNAcZvhI1M8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775772631; x=1776377431; 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=9OYRv8rvi0/sGy/tiETryCkJVCR2waOffWO1EsBR59E=; b=hH/V/3ztJDQj4okGnMoEDXmsaZN9PLtmIPpl4gcqJeLW57aZ7K1udpoThM7vvS3jWM 8jQfr9iimyaPGoaaM8ZxkOhcyt7f90/5h+O61apqnDCXcQq+BYkfgAHltLAcrPWlo7fx wMaz0Of/FQ4IiCsnieDiXkwYvgSejUotWzNZsSH2LrkG04gMRpC15Ml9ygUMODVrHukD tTZ9pPrki/3qH5DhxZmET3s8bZJQwDOqAoFB1xjAhpbsYkgjmwWTx3tEL4QK/QJMNzAp IKRMKj1TMuNqt5/24lmWj29EnO7MSWQLvmLfW3lwY3Z2VC+0gNBPFerhJ02qj5ezv5sI AZEA== X-Forwarded-Encrypted: i=1; AJvYcCVURREvygRqys5LNpq3837wkfKo3YuWSRKFCHryKFibrIT2UJsF4qNrd/AseFqW/tskKEwiPU594tKuC/4=@vger.kernel.org X-Gm-Message-State: AOJu0YwdWCxclwnT5W1iUSAo4Dsjsn1EKAwn6sBmSbQUfzKF9et6t++W fxd70fNzuDq0jJZT1vkFy9Cit7zJWy1ymLNMpGXK8z3OkWchUFvrSPXAIQ76KjNqY987WXQueJ8 tQ58kOkSS3AHqfioupgTGnVpKbIqPQnJlExgCg1xW/A== X-Gm-Gg: AeBDietFyfvZeIs5np9w9oyStfMWMNlQ42aUvpJKOJ58Y53YCJ+P3BcpEzcSyj9Kig0 JqeL7XU3Ntr0XvfNC2pNq0EhUbgXPmz81kF/D32p5TVIrNEDQhvKGeCMofkeIrEreGjxO2V6D95 bPTDy8WGOXo19d5HSZYPgVBZNnhdo95NZYmzfvROudB0kzz3sulMhfKhypssm1La46PZE0KUa/Y SQWCsfDYyzfdgQoL/NaJgX2JqccdXZQTpZ1p8I9lrVyOyNAYO4u1Gg5dojNAVwBUEgzHneLdIiD KY4YTL7tVv9qGDrnjICNurVY0ni66ReZA5BJzelrQg/8067+25wTQez/dcpE1wcLSm8psdHuQG8 d2dZZXU5Ivl5NVqeRNhgd+Opl0YK5eqtLeZHjulInBUCYvJEkLBrS+3VkyTmVpYY= X-Received: by 2002:a05:690c:101:b0:79a:d067:1b4c with SMTP id 00721157ae682-7af6f22b14emr7813727b3.7.1775772631395; Thu, 09 Apr 2026 15:10:31 -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: Thu, 9 Apr 2026 15:10:20 -0700 X-Gm-Features: AQROBzCM67wdyRTF025m1tdh9-7YRagOsrTvvnfPYDG5A2v0aHgobJFekGQYxnM Message-ID: Subject: [PATCH v3] 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 Reviewed-by: Kevin Tian --- drivers/iommu/iommufd/io_pagetable.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/iommu/iommufd/io_pagetable.c b/drivers/iommu/iommufd/io_pagetable.c index ee003bb2f647..e306871de06d 100644 --- a/drivers/iommu/iommufd/io_pagetable.c +++ b/drivers/iommu/iommufd/io_pagetable.c @@ -814,6 +814,14 @@ 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; + } else { + start =3D area_last + 1; + } } out_unlock_iova: -- 2.43.0