Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp1707808rdb; Mon, 8 Jan 2024 07:50:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IGXRzTbTTpN1d3MS0mv30g4dRumzqGUSIn0jJQyg48rOvWQkZBwlpM8/l6MjuSL6EQJsfSu X-Received: by 2002:a05:6e02:1a81:b0:35f:df6e:b0c7 with SMTP id k1-20020a056e021a8100b0035fdf6eb0c7mr4615254ilv.39.1704729019260; Mon, 08 Jan 2024 07:50:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704729019; cv=none; d=google.com; s=arc-20160816; b=e3TD9h4bcJN0sOhtshZhf2FI6rrvc0oC6My9f8EJnoTm9NOTtwiSzI7tNPc8mYgs7O SH21NyKY1BdY+Zi1LtJe70JXGPAMKh6hFtrGIilM5a51oY2UIQ+kASIiMcUWAyC6N0gF PcgCkSV95mxhKPZKMyUvGSfzOovrKoWC4WEtmtEo9LnC6suGXbuqGDgseRXSxAiLCmq2 wM2ehYRbGjI/5SDuY5AUV/CLpcDixtRAfEnRm+WTC2EAIxBn0u7hpu1OV7Rf/+KD9OQA tEqR2SKEpk8NnLVRw5cyxyB8oo4BmO59kPOekFeiapP/c6lJ4i39+owxbqLHly9vbPg/ 053A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=i1xKboGf9CulnX9K9gUfay8l0OIQaVSFEHmh+cj9Nwc=; fh=IpW+n4dhrO6i/N5UnismfCPlxTmm4pQF3m8KgZtFVcM=; b=J+WyVTJe8Kd2XX2g6wvS2V+V8QvvXrNOZmFcpD5mhpCRjxUf9w6cW6BXXidAR57Kvp BLPaS3wGoIc47nKMzk287emuvg+EpHBmmGoCMWdTesPYF4Pja9BOPZsdDlzqDnEhd5WW rG9wPhgpGvqD28MIxJ9CryDFW88EjQDGpCa2R8qgm9DWQ4DVaHyf2Ry7I2xsOzyLPGrE kMQO6YbS+Jhk8HtfbxmWgXYkhCAD4A+5DXK1zP+G7XKeW3kPG+Jp46DPo1lKhyfoH3vN d/e/AX6ObH+avTVzjIf+p5AXVzt6Ts1QxLGaDRriS9uVH1TRdHBaDaKU4Y0n0R68GtuY icNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-19801-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19801-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei-partners.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id cl4-20020a056a02098400b005bd3d377a54si28054pgb.123.2024.01.08.07.50.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 07:50:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19801-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-19801-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19801-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei-partners.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id E519AB23887 for ; Mon, 8 Jan 2024 15:47:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A51E8524BE; Mon, 8 Jan 2024 15:46:45 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (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 8F5E25103F for ; Mon, 8 Jan 2024 15:46:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei-partners.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei-partners.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4T7z081kdMz6FGpG; Mon, 8 Jan 2024 23:44:56 +0800 (CST) Received: from frapeml500002.china.huawei.com (unknown [7.182.85.205]) by mail.maildlp.com (Postfix) with ESMTPS id BAE0F1404F5; Mon, 8 Jan 2024 23:46:39 +0800 (CST) Received: from [10.126.171.78] (10.126.171.78) by frapeml500002.china.huawei.com (7.182.85.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 8 Jan 2024 16:46:38 +0100 Message-ID: Date: Mon, 8 Jan 2024 16:46:35 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] swiotlb: check alloc_size before the allocation of a new memory pool To: Peng Zhang , , , , , CC: , References: <20240108140005.3355316-1-zhangpeng362@huawei.com> Content-Language: en-US From: Petr Tesarik In-Reply-To: <20240108140005.3355316-1-zhangpeng362@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: frapeml100001.china.huawei.com (7.182.85.63) To frapeml500002.china.huawei.com (7.182.85.205) On 1/8/2024 3:00 PM, Peng Zhang wrote: > From: ZhangPeng > > The allocation request for swiotlb contiguous memory greater than > 128*2KB cannot be fulfilled because it exceeds the maximum contiguous > memory limit. If the swiotlb memory we allocate is larger than 128*2KB, > swiotlb_find_slots() will still schedule the allocation of a new memory > pool, which will increase memory overhead. > > Fix it by adding a check with alloc_size no more than 128*2KB before > scheduling the allocation of a new memory pool in swiotlb_find_slots(). > > Signed-off-by: ZhangPeng > --- > kernel/dma/swiotlb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c > index 33d942615be5..cc92cff02c60 100644 > --- a/kernel/dma/swiotlb.c > +++ b/kernel/dma/swiotlb.c > @@ -1126,6 +1126,9 @@ static int swiotlb_find_slots(struct device *dev, phys_addr_t orig_addr, > u64 phys_limit; > int index; > > + if (alloc_size > IO_TLB_SEGSIZE * IO_TLB_SIZE) > + return -1; > + > rcu_read_lock(); > list_for_each_entry_rcu(pool, &mem->pools, node) { > index = swiotlb_pool_find_slots(dev, pool, orig_addr, IIUC this such big allocations are not normally required by drivers, but I have already run into a similar issue with a Raspberry Pi 4 dma-buf object, so they can be triggered at will by user space. I also believe this sanity check is a good idea in general, not only when dynamic SWIOTLB is enabled. Reviewed-by: Petr Tesarik Petr T