Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp76021rdd; Mon, 8 Jan 2024 18:34:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IGIuVadMtnD1HQcPOnBdhMh66+6XxrT5Xct8lZlWA7MV7GLUdJqO69VvNNCu/Ia9EdyPgnC X-Received: by 2002:a17:906:5f99:b0:a28:adca:42c with SMTP id a25-20020a1709065f9900b00a28adca042cmr155255eju.72.1704767672294; Mon, 08 Jan 2024 18:34:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704767672; cv=none; d=google.com; s=arc-20160816; b=PSfUgyDpftPJ+4fs7XzH9adsDUOcDwlN4tbvC1k+qNpPYiqVdZfnggL9xbz8kCWb/0 PZafN1QqJptKRLxwJrJIJ2IVprT3AywvbMzbdz0/OXr+uQqqSrdkCqNmv1yZW7OPyFU3 qr1n4c2vYcjFBEprREkTUrxy2xrs+i7ITmXNs+loIKqEnV8EeBlk+lgCT0HjV9ATX3+c CaNcdHFRngZEV8Xh2M9jlpZwjdXw3m4m6z6VIwVvg+PIfOaRE2sBPhQ5PzqzdAOJ4IOi +vKcSKI85koIozZgLiEifLxuUYJpjUzDfUm6azH58euBe65d/+wSQsV8RTXFRgFMIhlc tFmA== 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:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=lg+0xfD32yu1R4QwgkLRkeNkmpG+PrZgT90TRix6nVM=; fh=yTqLkg26aFPypIvXGHmZ8CDjIpwg9g9xOIziVemxetQ=; b=LXJNLxHFqoaRixWC8Swe8zRlo9qzNbKYCGiMy/hbWYX44nc1MKiOrFZJ0aTFUgJWcp RV5pNwYEyCWICzdPAL1aB4WZEJJiGWSrm8jsqna50nroG/GBKEpEM1/4GOdtrQi3VAwv cxQP7H79mzxI8tkbuhMDy39JzJnahcyANkE0NwG4FXKgK0bItRWWIWQY/btayrAOL2VM xxPyt4l16A03wcAfMcRMNgNGfEWdaPa+U7V8ZC8ynf/uTIPbe02AaTN1ecGALaHyBGlb rUZXsKoEfOFHsOz7LCY2l4U3xhKwZ6K72IP61EctxocONvM5N9AwZiz1QHqZbO28V7L7 ivVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-20290-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-20290-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a26-20020a1709066d5a00b00a2ae6bc2944si394287ejt.476.2024.01.08.18.34.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 18:34:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-20290-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-20290-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-20290-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.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 am.mirrors.kernel.org (Postfix) with ESMTPS id F21501F24319 for ; Tue, 9 Jan 2024 02:34:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2715428FE; Tue, 9 Jan 2024 02:34:23 +0000 (UTC) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) (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 412C0187E for ; Tue, 9 Jan 2024 02:34:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4T8FJh5MXHz1FJ1G; Tue, 9 Jan 2024 10:30:12 +0800 (CST) Received: from kwepemm600020.china.huawei.com (unknown [7.193.23.147]) by mail.maildlp.com (Postfix) with ESMTPS id B134C1800C8; Tue, 9 Jan 2024 10:34:17 +0800 (CST) Received: from [10.174.179.160] (10.174.179.160) by kwepemm600020.china.huawei.com (7.193.23.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 9 Jan 2024 10:34:16 +0800 Message-ID: <237db58a-18ad-b3ea-7559-3c22169cba26@huawei.com> Date: Tue, 9 Jan 2024 10:34:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] swiotlb: check alloc_size before the allocation of a new memory pool Content-Language: en-US To: Petr Tesarik , , , , , CC: , References: <20240108140005.3355316-1-zhangpeng362@huawei.com> From: "zhangpeng (AS)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600020.china.huawei.com (7.193.23.147) On 2024/1/8 23:46, Petr Tesarik wrote: > 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 Thanks for your review! -- Best Regards, Peng