Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5403775pxj; Wed, 23 Jun 2021 00:01:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTCEqBdGhUwQoa6+bOO4zg8I1rLd5NiIfU5HOodR5zJy4IaQBZB//o+YWTh5iaYHI4iUos X-Received: by 2002:a92:c52f:: with SMTP id m15mr1717195ili.293.1624431665294; Wed, 23 Jun 2021 00:01:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624431665; cv=none; d=google.com; s=arc-20160816; b=zlwzC0O1UtX69E2mx6/fuuvYvE8rtTXzPORJzfrPu+wiGV2Wx+OR2cCJU/yw/dWjRD iUeiN6clDXKg1zIq93ng5a5J5kl0D0hm8CvN3cclNKD2KqXEEBWtaYwKgg+iP8Pv6brM pfC8ll8UowPRpvHekLCoJkd7FlyaJlLlvnq2uW1rZEVP2552P/eDVe4T6Uyzu4/g/tp1 7vjAZiKHFyrYrAA5C86rJDmdU0Qm1r7heL9bfwLtmGwrPaNlxTc5AzMl6NgJ2ZgZTUy5 8joQ3TSXY3fb/Y2FsEn65rpEDLn8S6Qmk+r3BHMjwt7EjAD+jyZQk/+bFknYljNhOIn4 JLSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=EoCYEd79VH2qW6GH2b3eqHMJYigm5G7+MLRNDijF8eU=; b=fwYkF4DsOnYQQpu1bzWCNaKQZKiLk+JJxTfSOfCITlUumMObaQ1PE1Xw0DxdooW53a 9oKA70TTc+1sX/64Y/Kf/9l7n6exgsun+lEC8ZLGHodsukLLIrel6jozxLiwktd6Jqj9 e7tXN6oRNrgcri7I3jfLhfSZGi/siXqSotFWeiYUJWylYdJ4U7viKfOTVX0gOE5ZJN+o pa2jL4IDFN8g6Eua883Q8MhjSoA6/37BF1kJtXxCd4zpnQnRfxQCOec/oyZEvM69y6N3 a4wZmw57d3Y8HQTD3zwy/1oq2F1fMBmcd+7ompV5UI0i1X8oGc5NY3yJIntTdSt+gIXL 29yg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x6si24581459iol.30.2021.06.23.00.00.52; Wed, 23 Jun 2021 00:01:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229892AbhFWHCa (ORCPT + 99 others); Wed, 23 Jun 2021 03:02:30 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:11084 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229775AbhFWHCZ (ORCPT ); Wed, 23 Jun 2021 03:02:25 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4G8vFp5tCTzZhys; Wed, 23 Jun 2021 14:57:02 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 23 Jun 2021 15:00:00 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 23 Jun 2021 14:59:59 +0800 Subject: Re: [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA From: Kefeng Wang To: Greg KH , Jing Xiangfeng CC: Nicolas Saenz Julienne , , , , , , , , , , , , , Li Huafei References: <20210303073319.2215839-1-jingxiangfeng@huawei.com> <9bc396116372de5b538d71d8f9ae9c3259f1002e.camel@suse.de> <827b317d7f5da6e048806922098291faacdb19f9.camel@suse.de> <604597E3.5000605@huawei.com> <31cd8432-2466-555d-7617-ae48cbcd4244@huawei.com> Message-ID: <8b0a4f25-0803-9341-f3a4-277d16802295@huawei.com> Date: Wed, 23 Jun 2021 14:59:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <31cd8432-2466-555d-7617-ae48cbcd4244@huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, There are two more patches about the ZONE_DMA[32] changes, especially the second one, both them need be backported, thanks. 791ab8b2e3db - arm64: Ignore any DMA offsets in the max_zone_phys() calculation 2687275a5843 - arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is required On 2021/5/11 20:35, Kefeng Wang wrote: > > > On 2021/3/8 17:58, Greg KH wrote: >> On Mon, Mar 08, 2021 at 11:20:03AM +0800, Jing Xiangfeng wrote: >>> >>> >>> On 2021/3/7 23:24, Greg KH wrote: >>>> On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote: >>>>> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote: >>>>>> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne >>>>>> wrote: >>>>>>> Hi Greg. >>>>>>> >>>>>>> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote: >>>>>>>> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote: >>>>>>>>> Using two distinct DMA zones turned out to be problematic. >>>>>>>>> Here's an >>>>>>>>> attempt go back to a saner default. >>>>>>>> What problem does this solve?  How does this fit into the stable >>>>>>>> kernel >>>>>>>> rules? >>>>>>> We changed the way we setup memory zones in arm64 in order to >>>>>>> cater for >>>>>>> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower >>>>>>> 1GB of memory >>>>>>> and ZONE_DMA32 the rest of the 32bit address space. Since you >>>>>>> can't allocate >>>>>>> memory that crosses zone boundaries, this broke crashkernel >>>>>>> allocations on big >>>>>>> machines. This series fixes all this by parsing the HW >>>>>>> description and checking >>>>>>> for DMA constrained buses. When not found, the unnecessary zone >>>>>>> creation is >>>>>>> skipped. >>>>>> What kernel/commit caused this "breakage"? >>>>> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32 >>>> Thanks for the info, all now queued up. >>> There is a fix in 5.11. Please consider applying the following commit to >>> 5.10.y: >>> >>> aed5041ef9a3 of: unittest: Fix build on architectures without >>> CONFIG_OF_ADDRES >> >> Thanks, now queued up. > > Hi Grep, another commit d78050ee3544 "arm64: Remove > arm64_dma32_phys_limit and its uses" should be involved, thanks. > > "Prior to this patch, disabling CONFIG_ZONE_DMA32 leads to CMA > allocation from the whole RAM as arm64_dma32_phys_limit becomes > PHYS_MASK+1." from Catalin, see more from the link > https://www.spinics.net/lists/arm-kernel/msg867356.html >> >> greg k-h >> . >>