Received: by 10.213.65.68 with SMTP id h4csp210689imn; Fri, 30 Mar 2018 18:32:13 -0700 (PDT) X-Google-Smtp-Source: AIpwx48q/OkvLKhVk3prIkKSHZm8v/rmXex7IEi1iigrdBNcoQ101G8rdHAgcEQnRvZF0m8VKjIP X-Received: by 2002:a17:902:8c88:: with SMTP id t8-v6mr1170551plo.329.1522459933085; Fri, 30 Mar 2018 18:32:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522459933; cv=none; d=google.com; s=arc-20160816; b=tAa0UPbQKH5Kdjv6I6hyzf/8rbX+fs76Da9J2og/gx7f2c6EZYFNokOiSOeEOII4pJ JJ/DOFHQT036FjGRQEen5EVeyDXWAj5bdP3QJIz24NWjS1mBl+L34s4MA+krreDKKB7s 5nOmT/zwGxP2d0PjfsX0ce1mLXfCydXDdAJU68JUUGc0z+oa7S88TuJTTKtQAUyFd0vC WEVnViFNvJmRO8gqiDsvDhx68/tJh/W3XMBPFjxCBdqJ6TFZvoSb0VrhcwhA2FQqeLVC 772yM0PRbxzZGfUP/h7PmZSjVYxWY3G7/VSZBujd6tgpEysPeE+c3RShYo43Mau6X2d3 s1Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=iqmlgjlH2qirB/92UafUW+Lb4NjEKSk0OiYMK4fv7Ug=; b=isiyEsgeILf2et/Q/iJHWnvGnqViTwgS4Upp3eXTtx9hFjdhkc39k+MTY7bac0hRLE /S3R1PdESt+oW9enGMRKsyGcRSNj1XHFoxux6gxC5pf2fPd4CmjYt1qQLB4OE4S7McRo 868z8LweXC9mKSdJsQS65IBA0gZ4YuBGZm8H87ZmXCrTPDzJpE8mS5AXynEOpl+8sjwH mwQe3T4iUZyrIS1/K3npsJFboowfsVQt8sI7VvMzzCqn4kkg+k+wkUkRoGIOnTO6ZA1N uHJFstseC3zqyJG7QKj5bxa6zOtCbdeI9NiLdaGK8S8abUqEX3CBO3zpWFyV1YPLwhN3 mttQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si6693660plw.143.2018.03.30.18.31.24; Fri, 30 Mar 2018 18:32:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752811AbeCaB1u (ORCPT + 99 others); Fri, 30 Mar 2018 21:27:50 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:7139 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752603AbeCaB1t (ORCPT ); Fri, 30 Mar 2018 21:27:49 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 29609F5D0561D; Sat, 31 Mar 2018 09:27:35 +0800 (CST) Received: from [127.0.0.1] (10.177.29.40) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.361.1; Sat, 31 Mar 2018 09:27:29 +0800 Subject: Re: [RFC PATCH] lib/ioremap: Avoid triggering BUG_ON when end is not PAGE_ALIGN To: "Kani, Toshi" , "akpm@linux-foundation.org" References: <1522385385-7074-1-git-send-email-xieyisheng1@huawei.com> <1522431689.2693.290.camel@hpe.com> CC: "linux-kernel@vger.kernel.org" , "guohanjun@huawei.com" , "tanxiaojun@huawei.com" , "wangzhou1@hisilicon.com" , "kstewart@linuxfoundation.org" , "gregkh@linuxfoundation.org" , "linux-arch@vger.kernel.org" , "arnd@arndb.de" , "jcm@redhat.com" From: Yisheng Xie Message-ID: <9c186ae8-6350-e1ab-001a-23ae87ce030d@huawei.com> Date: Sat, 31 Mar 2018 09:27:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1522431689.2693.290.camel@hpe.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.40] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Toshi, On 2018/3/31 1:41, Kani, Toshi wrote: > On Fri, 2018-03-30 at 12:49 +0800, Yisheng Xie wrote: >> Zhou reported a bug on Hisilicon arm64 D06 platform with 64KB page size: > : >> The cause is the size of PCI IO resource is 32KB, which is 4K aligned but >> not 64KB aligned, so when do ioremap_pte_range(), its incoming end is not >> PAGE_ALIGN on 64KB page size system, but ioremap_pte_range increase the >> addr by PAGE_SIZE, which makes addr != end until trigger BUG_ON. >> >> This patch introduces pte_addr_end(addr, end) to resolve this problem, just >> as what pmd_addr_end do. When end is not PAGE_ALIGN, it will return end >> instead of addr + PAGE_SIZE, therefore ioremap_pte_range() can break out >> when real end is coming. > > ioremap_pte_range() assumes that addr and end are aligned by PAGE_SIZE. > While some improvement can be made in the range check and documentation, > I do not think it is safe for letting this library function to map > outside of a requested range blindly. > > Can you change the caller of ioremap_page_range() to align the request > by PAGE_SIZE so that the caller is aware of what it's asking for? Sure, as the name of ioremap_*page*_range(), the caller should make sure align the request by PAGE_SIZE. Thanks Yisheng > > Thanks, > -Toshi >