From nobody Sat Sep 21 08:24:03 2024 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 B4CF7C5479D for ; Wed, 11 Jan 2023 06:50:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235679AbjAKGuJ (ORCPT ); Wed, 11 Jan 2023 01:50:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235783AbjAKGtm (ORCPT ); Wed, 11 Jan 2023 01:49:42 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3564410FDD; Tue, 10 Jan 2023 22:49:30 -0800 (PST) X-UUID: 176049ba917c11ed945fc101203acc17-20230111 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:MIME-Version:Message-ID:Date:Subject:CC:To:From; bh=YikO2rLCDulYaB/XHgOkJoUwL+d1QDp6nQB4HqkscJU=; b=nQ7yCIi9DmKQ9YNjzUmnJdzUzpdDKXl+/OF4NjrNDhyNnrUbv8L+E6Yls68YSnFTnGlV7qOyuF+Wi8lDi3CPYiSVTFLi/nRLPmoqds19rsV1kwivX22hrLJuY68RmxXqC9f7Dko7i1G7jWY+cs8x33esDixqp+s3JicJaoJzm9M=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.17,REQID:05102e29-76ff-4b9c-bf6c-9e56d9f78b9c,IP:0,U RL:0,TC:0,Content:-25,EDM:0,RT:0,SF:95,FILE:0,BULK:0,RULE:Release_Ham,ACTI ON:release,TS:70 X-CID-INFO: VERSION:1.1.17,REQID:05102e29-76ff-4b9c-bf6c-9e56d9f78b9c,IP:0,URL :0,TC:0,Content:-25,EDM:0,RT:0,SF:95,FILE:0,BULK:0,RULE:Spam_GS981B3D,ACTI ON:quarantine,TS:70 X-CID-META: VersionHash:543e81c,CLOUDID:e4b2ec8b-8530-4eff-9f77-222cf6e2895b,B ulkID:230111144927FF2QD1BA,BulkQuantity:0,Recheck:0,SF:38|28|17|19|48,TC:n il,Content:0,EDM:-3,IP:nil,URL:11|1,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0 ,OSI:0,OSA:0 X-CID-APTURL: Status:success,Category:nil,Trust:0,Unknown:0,Malicious:0 X-CID-BVR: 0 X-UUID: 176049ba917c11ed945fc101203acc17-20230111 Received: from mtkmbs10n1.mediatek.inc [(172.21.101.34)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 344695001; Wed, 11 Jan 2023 14:49:27 +0800 Received: from mtkmbs13n2.mediatek.inc (172.21.101.108) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 11 Jan 2023 14:49:26 +0800 Received: from mbjsdccf07.mediatek.inc (10.15.20.246) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Wed, 11 Jan 2023 14:49:24 +0800 From: To: Robin Murphy , Joerg Roedel , "Will Deacon" , Matthias Brugger , "open list:IOMMU DMA-API LAYER" , open list , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" CC: , , Libo Kang , Yong Wu , Ning Li , jianjiao zeng , "Yunfei Wang" Subject: [PATCH v2] iommu/iova: Fix alloc iova overflows issue Date: Wed, 11 Jan 2023 14:38:00 +0800 Message-ID: <20230111063801.25107-1-yf.wang@mediatek.com> X-Mailer: git-send-email 2.18.0 MIME-Version: 1.0 X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yunfei Wang In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful. This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node. Example log as follows: [ 223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [ 223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff 2. The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain. After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue. Signed-off-by: jianjiao zeng Signed-off-by: Yunfei Wang Cc: # 5.15.* Acked-by: Robin Murphy --- v2: Update patch 1. Cc stable@vger.kernel.org This patch needs to be merged stable branch, add stable@vger.kernel.org in mail list. 2. Refer robin's suggestion to update patch. --- drivers/iommu/iova.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index a44ad92fc5eb..fe452ce46642 100644 --- a/drivers/iommu/iova.c +++ b/drivers/iommu/iova.c @@ -197,7 +197,7 @@ static int __alloc_and_insert_iova_range(struct iova_do= main *iovad, =20 curr =3D __get_cached_rbnode(iovad, limit_pfn); curr_iova =3D to_iova(curr); - retry_pfn =3D curr_iova->pfn_hi + 1; + retry_pfn =3D curr_iova->pfn_hi; =20 retry: do { @@ -211,7 +211,7 @@ static int __alloc_and_insert_iova_range(struct iova_do= main *iovad, if (high_pfn < size || new_pfn < low_pfn) { if (low_pfn =3D=3D iovad->start_pfn && retry_pfn < limit_pfn) { high_pfn =3D limit_pfn; - low_pfn =3D retry_pfn; + low_pfn =3D retry_pfn + 1; curr =3D iova_find_limit(iovad, limit_pfn); curr_iova =3D to_iova(curr); goto retry; --=20 2.18.0