Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3431039pxv; Sun, 4 Jul 2021 19:12:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRMMs9BIhWhcDt0mYpkSPy5p9iTee48bIuPYEbatLzuvDAm4uDsG4cRnLtlAVYYXmOzCGf X-Received: by 2002:a17:906:7393:: with SMTP id f19mr11026293ejl.533.1625451171652; Sun, 04 Jul 2021 19:12:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625451171; cv=none; d=google.com; s=arc-20160816; b=szw+kCDpnbIveHeflx80RSB7U+ZOU+1qyBgM04ibacS72KGQjamee+F2/FRtFLpGS9 AUJHMCJ0dbH6DD5OKJVuWAqqDDFkTnnojBkmy0cLeEy1KwGUcO4bSi25wnSupifSRTWu 1w6+lekG8HSY/YlWRarlvjr8uGQ2kX7brVbFc7AgYbtu1VnIm0vh+SiNR7Ym/YZ+4tGL QvyoUE8NhLTZq0Ic2MFku/TMixQVl2WDA+a3Z0zcK71KJzYdyc6EfR+l/fUwxvysQC1g JABcKT/THDF+YfI+vPd0KGga8C7o9wqPdG/hpgu0zrkKGpbMashrQtGpW58OtuTXm7XA 7dPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=A7Y8FCBj5AxkNWekRB6qCgGZuezmnMqCFZZYu4MB/FI=; b=IAgspP3jLkr8MXlMMFl1KPCQBCtADPO2wIsUuxp6+8fJjNlIsUwfZSkKwSnaaXJpFk wjVHy1bbBOmzBwTAQymiv4tW6kWDpL58GOA8WC6oKP1YnwAoV8czezdAiItN+10qsiQZ reook0b9b0XAJNU8h6xwZAXS/Nr4fpO44VhM3TpeMcv1fy54KBJEHXBhypt7pDG6LLiQ 3Luootp1sEfrOeXC73Y8loV0Dr47pnFbTca57TkQSaPhu84WRPxAJ+oXpOFeCgBaz7r2 +OZOjUNuvPVoV0eFyUpYp73PQ+sUm18MzCkbJ8nIGOnAexxc2BQHH5RHHtaz/z/0hWTc QBNA== 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=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y7si9403077edw.145.2021.07.04.19.12.29; Sun, 04 Jul 2021 19:12:51 -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=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229713AbhGECOL (ORCPT + 99 others); Sun, 4 Jul 2021 22:14:11 -0400 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:36056 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbhGECOL (ORCPT ); Sun, 4 Jul 2021 22:14:11 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=alimailimapcm10staff010182156082;MF=yaohuiwang@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0UegSsAS_1625451092; Received: from Dillions-MBP-16.local(mailfrom:yaohuiwang@linux.alibaba.com fp:SMTPD_---0UegSsAS_1625451092) by smtp.aliyun-inc.com(127.0.0.1); Mon, 05 Jul 2021 10:11:33 +0800 Subject: Re: [PATCH v3 1/2] x86/ioremap: fix the pfn calculation mistake in __ioremap_check_ram() To: Dave Hansen , tglx@linutronix.de Cc: luto@kernel.org, peterz@infradead.org, mingo@redhat.com, bp@alien8.de, x86@kernel.org, linux-kernel@vger.kernel.org, luoben@linux.alibaba.com, Tom Lendacky , Brijesh Singh References: <20210621123419.2976-1-yaohuiwang@linux.alibaba.com> <20210621123419.2976-2-yaohuiwang@linux.alibaba.com> <94a38542-b639-37e4-1b53-29b59c5ea655@intel.com> <34bae667-180f-ce97-ee55-12e13ff28ca0@linux.alibaba.com> <663229c2-1957-2af5-678c-5d553507f5f3@intel.com> From: Yaohui Wang Message-ID: Date: Mon, 5 Jul 2021 10:11:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <663229c2-1957-2af5-678c-5d553507f5f3@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/7/2 22:49, Dave Hansen wrote: > Do you know why this check: > >> if ((res->flags & IORESOURCE_SYSTEM_RAM) != IORESOURCE_SYSTEM_RAM) >> return false; > > did not catch your out-of-tree driver's errant ioremap()? > If ioremap() is invoked on an area that contains normal memory, then: (res->flags & IORESOURCE_SYSTEM_RAM) == IORESOURCE_SYSTEM_RAM) is true, so the original check is false. The code following the check will continue to scan whether this area contains any page that is not PageReserved (i.e. that is truly normal RAM). Your idea should be: if ((res->flags & IORESOURCE_SYSTEM_RAM) == IORESOURCE_SYSTEM_RAM) return IORES_MAP_SYSTEM_RAM; But this check is too strict as IORESOURCE_SYSTEM_RAM area may contain PageReserved pages, and PageReserved pages should be ioremap-able. So the checking logic of the original __ioremap_check_ram() function is reasonable.