Message ID | 20230515090848.833045-15-bhe@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp6786742vqo; Mon, 15 May 2023 02:34:46 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6e1gRmuej8vyllprXIJZOY9vu4M+beqKDl6SsK7k1EN2OG3qsWILvn2RnA1wiG0/1+Htpd X-Received: by 2002:a05:6a20:9194:b0:f2:3d53:87b2 with SMTP id v20-20020a056a20919400b000f23d5387b2mr41630982pzd.31.1684143285817; Mon, 15 May 2023 02:34:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684143285; cv=none; d=google.com; s=arc-20160816; b=NAoiUK+YIPpYgMv+gIJEdp2KD712RvvaATlDFKQWy0ZdYyvBvaKb6RV5+p0MLpIGby BI8KI6G71Rd1hs1x6ZrHYSHP/vs3XvF5iDn9iTe+fJgIYbUpFM1Wr0buytXdUV+d6cvi lNMG0hlw+rjOpR3yqI5F/+J7tGNyN4eoeR+hJhOscU03C8Ab4/OsU58xDY/IgKQs7hnn i3MxjCKj1iEtqB5TE+ed3c/4kde+2sm6+RT1ekLSyoBL1KFwrk/NAgEgz44KInzB0PL7 21Go88FeZpiufdy4RV2O+tT42PvSAQrhxUT2e5oNFsS4k6KxRycqTrNSORHcHf0D9fDw Wj6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Uaseq8uUQQ6QMQSRfFux0A76lTwwiGZ3GmLj5/5Y0lk=; b=g1aC23tXMD2Khu5pNeXdw53Q7z2JpeFauVNQgHn2iy9ZgC01+tMx42GG7BkndCh3Cp GgjTbhE/PZJ787NVgDhwrfuaXRGiGyUCkZLyx+zxtJZatr8JSlqLIWC++C7Cj6ZyIIKp 0x26FmWYuq+6FMincaD5lZTN/bvneHjVI2KpW383ReRdXg2JJtQjDvzuigS2As9BT+eQ B7QcVqQEtc4en9N7ie6llCzvIM26UVKQWP5xYZfdKhvD751RpwO0V2VJMRuEBsR4TKxf UP8+uFN+lnYpnEZQqkctCFZ+KhiFM3jm663r0dVcjHccxrmidKQKb9Viptqo2tYStl06 4fcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="hLVtTz/W"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f67-20020a623846000000b0064105588e53si6561109pfa.359.2023.05.15.02.34.33; Mon, 15 May 2023 02:34:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="hLVtTz/W"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233814AbjEOJOR (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Mon, 15 May 2023 05:14:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229963AbjEOJN0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 15 May 2023 05:13:26 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FA49212E for <linux-kernel@vger.kernel.org>; Mon, 15 May 2023 02:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684141853; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Uaseq8uUQQ6QMQSRfFux0A76lTwwiGZ3GmLj5/5Y0lk=; b=hLVtTz/WvCwJgMNr78AO2M+yQj8iy7TzeGb4GBePRbSeCXcRrhCQJflHexF17iMuRJYJNr F78NI5sw+2Sx/AuWUc1BXlMuSa0LGNBAvEbFGNpkFO56SBp+qZySqdJ1SBTElb5qGC5EMw HIcVCCB3+kREV6TsGi26utEQCzirYIw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-507-ER6juC3BMNSvQDD-_oKHbw-1; Mon, 15 May 2023 05:10:50 -0400 X-MC-Unique: ER6juC3BMNSvQDD-_oKHbw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A324585A588; Mon, 15 May 2023 09:10:49 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-32.pek2.redhat.com [10.72.12.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3611340C2070; Mon, 15 May 2023 09:10:42 +0000 (UTC) From: Baoquan He <bhe@redhat.com> To: linux-kernel@vger.kernel.org Cc: linux-arch@vger.kernel.org, linux-mm@kvack.org, arnd@arndb.de, christophe.leroy@csgroup.eu, hch@infradead.org, agordeev@linux.ibm.com, wangkefeng.wang@huawei.com, schnelle@linux.ibm.com, David.Laight@ACULAB.COM, shorne@gmail.com, willy@infradead.org, deller@gmx.de, Baoquan He <bhe@redhat.com> Subject: [PATCH v5 RESEND 14/17] mm/ioremap: Consider IOREMAP space in generic ioremap Date: Mon, 15 May 2023 17:08:45 +0800 Message-Id: <20230515090848.833045-15-bhe@redhat.com> In-Reply-To: <20230515090848.833045-1-bhe@redhat.com> References: <20230515090848.833045-1-bhe@redhat.com> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765952230357620080?= X-GMAIL-MSGID: =?utf-8?q?1765952230357620080?= |
Series |
mm: ioremap: Convert architectures to take GENERIC_IOREMAP way
|
|
Commit Message
Baoquan He
May 15, 2023, 9:08 a.m. UTC
From: Christophe Leroy <christophe.leroy@csgroup.eu> Architectures like powerpc have a dedicated space for IOREMAP mappings. If so, use it in generic_ioremap_pro(). Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Baoquan He <bhe@redhat.com> --- mm/ioremap.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
Comments
On Mon, May 15, 2023 at 05:08:45PM +0800, Baoquan He wrote: > From: Christophe Leroy <christophe.leroy@csgroup.eu> > > Architectures like powerpc have a dedicated space for IOREMAP mappings. > > If so, use it in generic_ioremap_pro(). > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> > Signed-off-by: Baoquan He <bhe@redhat.com> Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> > --- > mm/ioremap.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/mm/ioremap.c b/mm/ioremap.c > index 2fbe6b9bc50e..4a7749d85044 100644 > --- a/mm/ioremap.c > +++ b/mm/ioremap.c > @@ -35,8 +35,13 @@ void __iomem *generic_ioremap_prot(phys_addr_t phys_addr, size_t size, > if (!ioremap_allowed(phys_addr, size, pgprot_val(prot))) > return NULL; > > +#ifdef IOREMAP_START > + area = __get_vm_area_caller(size, VM_IOREMAP, IOREMAP_START, > + IOREMAP_END, __builtin_return_address(0)); > +#else > area = get_vm_area_caller(size, VM_IOREMAP, > __builtin_return_address(0)); > +#endif > if (!area) > return NULL; > vaddr = (unsigned long)area->addr; > @@ -66,7 +71,7 @@ void generic_iounmap(volatile void __iomem *addr) > if (!iounmap_allowed(vaddr)) > return; > > - if (is_vmalloc_addr(vaddr)) > + if (is_ioremap_addr(vaddr)) > vunmap(vaddr); > } > > -- > 2.34.1 > >
On Mon, May 15, 2023 at 05:08:45PM +0800, Baoquan He wrote: > @@ -35,8 +35,13 @@ void __iomem *generic_ioremap_prot(phys_addr_t phys_addr, size_t size, > if (!ioremap_allowed(phys_addr, size, pgprot_val(prot))) > return NULL; > > +#ifdef IOREMAP_START > + area = __get_vm_area_caller(size, VM_IOREMAP, IOREMAP_START, > + IOREMAP_END, __builtin_return_address(0)); > +#else > area = get_vm_area_caller(size, VM_IOREMAP, > __builtin_return_address(0)); > +#endif I think this would be cleaner if we'd just always use __get_vm_area_caller and at the top of the file add a: #ifndef IOREMAP_START #define IOREMAP_START VMALLOC_START #define IOREMAP_END VMALLOC_END #endif Together with a little comment that ioremap often, but not always uses the generic vmalloc area.
On Tue, May 16, 2023 at 11:41:26PM -0700, Christoph Hellwig wrote: > I think this would be cleaner if we'd just always use > __get_vm_area_caller and at the top of the file add a: > > #ifndef IOREMAP_START > #define IOREMAP_START VMALLOC_START > #define IOREMAP_END VMALLOC_END > #endif > > Together with a little comment that ioremap often, but not always > uses the generic vmalloc area. .. and with that we can also simply is_ioremap_addr by moving it to ioremap.c and making it always operate on the IOREMAP constants.
On 05/16/23 at 11:41pm, Christoph Hellwig wrote: > On Mon, May 15, 2023 at 05:08:45PM +0800, Baoquan He wrote: > > @@ -35,8 +35,13 @@ void __iomem *generic_ioremap_prot(phys_addr_t phys_addr, size_t size, > > if (!ioremap_allowed(phys_addr, size, pgprot_val(prot))) > > return NULL; > > > > +#ifdef IOREMAP_START > > + area = __get_vm_area_caller(size, VM_IOREMAP, IOREMAP_START, > > + IOREMAP_END, __builtin_return_address(0)); > > +#else > > area = get_vm_area_caller(size, VM_IOREMAP, > > __builtin_return_address(0)); > > +#endif > > I think this would be cleaner if we'd just always use > __get_vm_area_caller and at the top of the file add a: > > #ifndef IOREMAP_START > #define IOREMAP_START VMALLOC_START > #define IOREMAP_END VMALLOC_END > #endif > > Together with a little comment that ioremap often, but not always > uses the generic vmalloc area. Great idea, will do as suggested.
On 05/16/23 at 11:44pm, Christoph Hellwig wrote: > On Tue, May 16, 2023 at 11:41:26PM -0700, Christoph Hellwig wrote: > > I think this would be cleaner if we'd just always use > > __get_vm_area_caller and at the top of the file add a: > > > > #ifndef IOREMAP_START > > #define IOREMAP_START VMALLOC_START > > #define IOREMAP_END VMALLOC_END > > #endif > > > > Together with a little comment that ioremap often, but not always > > uses the generic vmalloc area. > > .. and with that we can also simply is_ioremap_addr by moving it > to ioremap.c and making it always operate on the IOREMAP constants. Great idea too, will do. Put this into a separate patch?
On Sat, May 20, 2023 at 11:31:04AM +0800, Baoquan He wrote: > > > Together with a little comment that ioremap often, but not always > > > uses the generic vmalloc area. > > > > .. and with that we can also simply is_ioremap_addr by moving it > > to ioremap.c and making it always operate on the IOREMAP constants. > > Great idea too, will do. Put this into a separate patch? Yes.
On 05/16/23 at 11:44pm, Christoph Hellwig wrote: > On Tue, May 16, 2023 at 11:41:26PM -0700, Christoph Hellwig wrote: > > I think this would be cleaner if we'd just always use > > __get_vm_area_caller and at the top of the file add a: > > > > #ifndef IOREMAP_START > > #define IOREMAP_START VMALLOC_START > > #define IOREMAP_END VMALLOC_END > > #endif > > > > Together with a little comment that ioremap often, but not always > > uses the generic vmalloc area. > > .. and with that we can also simply is_ioremap_addr by moving it > to ioremap.c and making it always operate on the IOREMAP constants. In the current code, is_ioremap_addr() is being used in kernel/iomem.c. However, mm/ioremap.c is only built in when CONFIG_GENERIC_IOREMAP is enabled. This will impact those architectures which haven't taken GENERIC_IOREMAP way. [~]$ git grep is_ioremap_addr arch/powerpc/include/asm/pgtable.h:#define is_ioremap_addr is_ioremap_addr arch/powerpc/include/asm/pgtable.h:static inline bool is_ioremap_addr(const void *x) include/linux/mm.h:static inline bool is_ioremap_addr(const void *x) include/linux/mm.h:static inline bool is_ioremap_addr(const void *x) kernel/iomem.c: if (is_ioremap_addr(addr)) mm/ioremap.c: if (is_ioremap_addr(vaddr)) [bhe@MiWiFi-R3L-srv linux-arm64]$ git grep ioremap mm/Makefile mm/Makefile:obj-$(CONFIG_GENERIC_EARLY_IOREMAP) += early_ioremap.o mm/Makefile:obj-$(CONFIG_GENERIC_IOREMAP) += ioremap.o If we want to consolidate code, we can move is_ioremap_addr() to include/linux/mm.h libe below. Not sure if it's fine. With it, both kernel/iomem.c and mm/ioremap.c can use is_ioremap_addr(). diff --git a/include/linux/mm.h b/include/linux/mm.h index 27ce77080c79..0fbb94f0f025 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1041,9 +1041,25 @@ unsigned long vmalloc_to_pfn(const void *addr); * On nommu, vmalloc/vfree wrap through kmalloc/kfree directly, so there * is no special casing required. */ - -#ifndef is_ioremap_addr -#define is_ioremap_addr(x) is_vmalloc_addr(x) +#if defined(CONFIG_HAS_IOMEM) || defined(CONFIG_GENERIC_IOREMAP) +/* + * Ioremap often, but not always uses the generic vmalloc area. E.g on + * Power ARCH, it could have different ioremap space. + */ +#ifndef IOREMAP_START +#define IOREMAP_START VMALLOC_START +#define IOREMAP_END VMALLOC_END +#endif +static inline bool is_ioremap_addr(const void *x) +{ + unsigned long addr = (unsigned long)kasan_reset_tag(x); + return addr >= IOREMAP_START && addr < IOREMAP_END; +} +#else +static inline bool is_ioremap_addr(const void *x) +{ + return false; +} #endif #ifdef CONFIG_MMU
On Tue, May 30, 2023 at 05:37:23PM +0800, Baoquan He wrote: > If we want to consolidate code, we can move is_ioremap_addr() to > include/linux/mm.h libe below. Not sure if it's fine. With it, > both kernel/iomem.c and mm/ioremap.c can use is_ioremap_addr(). Can we just add a ne header for this given that no one else really needs it?
On 06/01/23 at 04:13am, Christoph Hellwig wrote: > On Tue, May 30, 2023 at 05:37:23PM +0800, Baoquan He wrote: > > If we want to consolidate code, we can move is_ioremap_addr() to > > include/linux/mm.h libe below. Not sure if it's fine. With it, > > both kernel/iomem.c and mm/ioremap.c can use is_ioremap_addr(). > > Can we just add a ne header for this given that no one else really > needs it? Is it OK like below? From fe5d4d25afa1e989fa82877c8466a97fc8bd8c93 Mon Sep 17 00:00:00 2001 From: Baoquan He <bhe@redhat.com> Date: Fri, 2 Jun 2023 18:36:48 +0800 Subject: [PATCH] mm: move is_ioremap_addr() into new header file Content-type: text/plain Now is_ioremap_addr() is only used in kernel/iomem.c and gonna be used in mm/ioremap.c. Move it into its own new header file linux/ioremap.h. Signed-off-by: Baoquan He <bhe@redhat.com> --- include/linux/ioremap.h | 29 +++++++++++++++++++++++++++++ include/linux/mm.h | 5 ----- kernel/iomem.c | 1 + mm/ioremap.c | 1 + 4 files changed, 31 insertions(+), 5 deletions(-) create mode 100644 include/linux/ioremap.h diff --git a/include/linux/ioremap.h b/include/linux/ioremap.h new file mode 100644 index 000000000000..2fd51a77ebdc --- /dev/null +++ b/include/linux/ioremap.h @@ -0,0 +1,29 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_IOREMAP_H +#define _LINUX_IOREMAP_H + +#include <linux/kasan.h> +#include <asm/pgtable.h> + +#if defined(CONFIG_HAS_IOMEM) || defined(CONFIG_GENERIC_IOREMAP) +/* + * Ioremap often, but not always uses the generic vmalloc area. E.g on + * Power ARCH, it could have different ioremap space. + */ +#ifndef IOREMAP_START +#define IOREMAP_START VMALLOC_START +#define IOREMAP_END VMALLOC_END +#endif +static inline bool is_ioremap_addr(const void *x) +{ + unsigned long addr = (unsigned long)kasan_reset_tag(x); + return addr >= IOREMAP_START && addr < IOREMAP_END; +} +#else +static inline bool is_ioremap_addr(const void *x) +{ + return false; +} +#endif + +#endif /* _LINUX_IOREMAP_H */ diff --git a/include/linux/mm.h b/include/linux/mm.h index 27ce77080c79..7379f19768b4 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1041,11 +1041,6 @@ unsigned long vmalloc_to_pfn(const void *addr); * On nommu, vmalloc/vfree wrap through kmalloc/kfree directly, so there * is no special casing required. */ - -#ifndef is_ioremap_addr -#define is_ioremap_addr(x) is_vmalloc_addr(x) -#endif - #ifdef CONFIG_MMU extern bool is_vmalloc_addr(const void *x); extern int is_vmalloc_or_module_addr(const void *x); diff --git a/kernel/iomem.c b/kernel/iomem.c index 62c92e43aa0d..9682471e6471 100644 --- a/kernel/iomem.c +++ b/kernel/iomem.c @@ -3,6 +3,7 @@ #include <linux/types.h> #include <linux/io.h> #include <linux/mm.h> +#include <linux/ioremap.h> #ifndef ioremap_cache /* temporary while we convert existing ioremap_cache users to memremap */ diff --git a/mm/ioremap.c b/mm/ioremap.c index 0248e630561b..3dede3302eba 100644 --- a/mm/ioremap.c +++ b/mm/ioremap.c @@ -10,6 +10,7 @@ #include <linux/mm.h> #include <linux/io.h> #include <linux/export.h> +#include <linux/ioremap.h> /* * Ioremap often, but not always uses the generic vmalloc area. E.g on
On Fri, Jun 02, 2023 at 06:42:59PM +0800, Baoquan He wrote: > On 06/01/23 at 04:13am, Christoph Hellwig wrote: > > On Tue, May 30, 2023 at 05:37:23PM +0800, Baoquan He wrote: > > > If we want to consolidate code, we can move is_ioremap_addr() to > > > include/linux/mm.h libe below. Not sure if it's fine. With it, > > > both kernel/iomem.c and mm/ioremap.c can use is_ioremap_addr(). > > > > Can we just add a ne header for this given that no one else really > > needs it? > > Is it OK like below? Looks good to me: Reviewed-by: Christoph Hellwig <hch@lst.de>
diff --git a/mm/ioremap.c b/mm/ioremap.c index 2fbe6b9bc50e..4a7749d85044 100644 --- a/mm/ioremap.c +++ b/mm/ioremap.c @@ -35,8 +35,13 @@ void __iomem *generic_ioremap_prot(phys_addr_t phys_addr, size_t size, if (!ioremap_allowed(phys_addr, size, pgprot_val(prot))) return NULL; +#ifdef IOREMAP_START + area = __get_vm_area_caller(size, VM_IOREMAP, IOREMAP_START, + IOREMAP_END, __builtin_return_address(0)); +#else area = get_vm_area_caller(size, VM_IOREMAP, __builtin_return_address(0)); +#endif if (!area) return NULL; vaddr = (unsigned long)area->addr; @@ -66,7 +71,7 @@ void generic_iounmap(volatile void __iomem *addr) if (!iounmap_allowed(vaddr)) return; - if (is_vmalloc_addr(vaddr)) + if (is_ioremap_addr(vaddr)) vunmap(vaddr); }