From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E1C6C61DA4 for ; Mon, 6 Feb 2023 08:41:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229759AbjBFIlV (ORCPT ); Mon, 6 Feb 2023 03:41:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229511AbjBFIlS (ORCPT ); Mon, 6 Feb 2023 03:41:18 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E77A317158 for ; Mon, 6 Feb 2023 00:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672836; 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=ZnCrWWx4pp/03QuBJCB11gBYLXEsVuMTBc/8ULu0oDY=; b=gi76awTwhHCVj+5BH4F5H6c+T2LQIenU9dYbZyulWvqRf/wixmWjOyYawftBrwIMD6dBYR OFRND0BPF6t3XUPLJOtBQ44AAqgMEGMg03bHdEEE3ivE5OQw57Yh95c2nPvnADYiCHYt5A dCLKiK85xQXVRSgMaUYokoVNcWXvhQ4= 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-244-qNwJhTElN9GeQaPmcH1H-w-1; Mon, 06 Feb 2023 03:40:32 -0500 X-MC-Unique: qNwJhTElN9GeQaPmcH1H-w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 74CF187B2A0; Mon, 6 Feb 2023 08:40:32 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5FC332166B2B; Mon, 6 Feb 2023 08:40:28 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 1/7] mm/vmalloc.c: add used_map into vmap_block to track space of vmap_block Date: Mon, 6 Feb 2023 16:40:14 +0800 Message-Id: <20230206084020.174506-2-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In one vmap_block area, there could be three types of regions: region being used which is allocated through vb_alloc(), dirty region which is freed via vb_free() and free region. Among them, only used region has available data. While there's no way to track those used regions currently. Here, add bitmap field used_map into vmap_block, and set/clear it during allocation or freeing regions of vmap_block area. This is a preparatoin for later use. Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes Reviewed-by: Uladzislau Rezki (Sony) --- mm/vmalloc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 428e0bee5c9c..d6ff058ef4d0 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1922,6 +1922,7 @@ struct vmap_block { spinlock_t lock; struct vmap_area *va; unsigned long free, dirty; + DECLARE_BITMAP(used_map, VMAP_BBMAP_BITS); unsigned long dirty_min, dirty_max; /*< dirty range */ struct list_head free_list; struct rcu_head rcu_head; @@ -1998,10 +1999,12 @@ static void *new_vmap_block(unsigned int order, gfp= _t gfp_mask) vb->va =3D va; /* At least something should be left free */ BUG_ON(VMAP_BBMAP_BITS <=3D (1UL << order)); + bitmap_zero(vb->used_map, VMAP_BBMAP_BITS); vb->free =3D VMAP_BBMAP_BITS - (1UL << order); vb->dirty =3D 0; vb->dirty_min =3D VMAP_BBMAP_BITS; vb->dirty_max =3D 0; + bitmap_set(vb->used_map, 0, (1UL << order)); INIT_LIST_HEAD(&vb->free_list); =20 vb_idx =3D addr_to_vb_idx(va->va_start); @@ -2111,6 +2114,7 @@ static void *vb_alloc(unsigned long size, gfp_t gfp_m= ask) pages_off =3D VMAP_BBMAP_BITS - vb->free; vaddr =3D vmap_block_vaddr(vb->va->va_start, pages_off); vb->free -=3D 1UL << order; + bitmap_set(vb->used_map, pages_off, (1UL << order)); if (vb->free =3D=3D 0) { spin_lock(&vbq->lock); list_del_rcu(&vb->free_list); @@ -2144,6 +2148,9 @@ static void vb_free(unsigned long addr, unsigned long= size) order =3D get_order(size); offset =3D (addr & (VMAP_BLOCK_SIZE - 1)) >> PAGE_SHIFT; vb =3D xa_load(&vmap_blocks, addr_to_vb_idx(addr)); + spin_lock(&vb->lock); + bitmap_clear(vb->used_map, offset, (1UL << order)); + spin_unlock(&vb->lock); =20 vunmap_range_noflush(addr, addr + size); =20 --=20 2.34.1 From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77BF5C61DA4 for ; Mon, 6 Feb 2023 08:41:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229978AbjBFIld (ORCPT ); Mon, 6 Feb 2023 03:41:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229915AbjBFIl2 (ORCPT ); Mon, 6 Feb 2023 03:41:28 -0500 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 B361117157 for ; Mon, 6 Feb 2023 00:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672840; 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=Cc8KcFYSac3hETCaiorDwaJuaLkn+gY3HkrQz3ErLWA=; b=BRYxDiScFFXISn5fpidbGU32dKk/OBc+BKlIuKLrZxjxMemPgHUyOcQQgXXGsM/UpWeCc0 S0MwT9Hu0jFJgQwj6XpUB5EptscVwbkaoy2AYwhwAo5IEe+MyDaCMYhN4L2uj83oYGvk36 BOCml2PnfWHXJ2PiIDrQNglQvXtD3x4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-607-OZuYdVm3Nn2c0Cg5-8Dgiw-1; Mon, 06 Feb 2023 03:40:37 -0500 X-MC-Unique: OZuYdVm3Nn2c0Cg5-8Dgiw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 440483811F25; Mon, 6 Feb 2023 08:40:37 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 424E02166B2A; Mon, 6 Feb 2023 08:40:32 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area Date: Mon, 6 Feb 2023 16:40:15 +0800 Message-Id: <20230206084020.174506-3-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Through vmalloc API, a virtual kernel area is reserved for physical address mapping. And vmap_area is used to track them, while vm_struct is allocated to associate with the vmap_area to store more information and passed out. However, area reserved via vm_map_ram() is an exception. It doesn't have vm_struct to associate with vmap_area. And we can't recognize the vmap_area with '->vm =3D=3D NULL' as a vm_map_ram() area because the normal freeing path will set va->vm =3D NULL before unmapping, please see function remove_vm_area(). Meanwhile, there are two kinds of handling for vm_map_ram area. One is the whole vmap_area being reserved and mapped at one time through vm_map_area() interface; the other is the whole vmap_area with VMAP_BLOCK_SIZE size being reserved, while mapped into split regions with smaller size via vb_alloc(). To mark the area reserved through vm_map_ram(), add flags field into struct vmap_area. Bit 0 indicates this is vm_map_ram area created through vm_map_ram() interface, while bit 1 marks out the type of vm_map_ram area which makes use of vmap_block to manage split regions via vb_alloc/free(). This is a preparation for later use. Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes Reviewed-by: Uladzislau Rezki (Sony) --- include/linux/vmalloc.h | 1 + mm/vmalloc.c | 16 ++++++++++++---- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 096d48aa3437..69250efa03d1 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -76,6 +76,7 @@ struct vmap_area { unsigned long subtree_max_size; /* in "free" tree */ struct vm_struct *vm; /* in "busy" tree */ }; + unsigned long flags; /* mark type of vm_map_ram area */ }; =20 /* archs that select HAVE_ARCH_HUGE_VMAP should override one or more of th= ese */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index d6ff058ef4d0..ab4825050b5c 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1589,7 +1589,8 @@ preload_this_cpu_lock(spinlock_t *lock, gfp_t gfp_mas= k, int node) static struct vmap_area *alloc_vmap_area(unsigned long size, unsigned long align, unsigned long vstart, unsigned long vend, - int node, gfp_t gfp_mask) + int node, gfp_t gfp_mask, + unsigned long va_flags) { struct vmap_area *va; unsigned long freed; @@ -1635,6 +1636,7 @@ static struct vmap_area *alloc_vmap_area(unsigned lon= g size, va->va_start =3D addr; va->va_end =3D addr + size; va->vm =3D NULL; + va->flags =3D va_flags; =20 spin_lock(&vmap_area_lock); insert_vmap_area(va, &vmap_area_root, &vmap_area_list); @@ -1913,6 +1915,10 @@ static struct vmap_area *find_unlink_vmap_area(unsig= ned long addr) =20 #define VMAP_BLOCK_SIZE (VMAP_BBMAP_BITS * PAGE_SIZE) =20 +#define VMAP_RAM 0x1 /* indicates vm_map_ram area*/ +#define VMAP_BLOCK 0x2 /* mark out the vmap_block sub-type*/ +#define VMAP_FLAGS_MASK 0x3 + struct vmap_block_queue { spinlock_t lock; struct list_head free; @@ -1988,7 +1994,8 @@ static void *new_vmap_block(unsigned int order, gfp_t= gfp_mask) =20 va =3D alloc_vmap_area(VMAP_BLOCK_SIZE, VMAP_BLOCK_SIZE, VMALLOC_START, VMALLOC_END, - node, gfp_mask); + node, gfp_mask, + VMAP_RAM|VMAP_BLOCK); if (IS_ERR(va)) { kfree(vb); return ERR_CAST(va); @@ -2297,7 +2304,8 @@ void *vm_map_ram(struct page **pages, unsigned int co= unt, int node) } else { struct vmap_area *va; va =3D alloc_vmap_area(size, PAGE_SIZE, - VMALLOC_START, VMALLOC_END, node, GFP_KERNEL); + VMALLOC_START, VMALLOC_END, + node, GFP_KERNEL, VMAP_RAM); if (IS_ERR(va)) return NULL; =20 @@ -2537,7 +2545,7 @@ static struct vm_struct *__get_vm_area_node(unsigned = long size, if (!(flags & VM_NO_GUARD)) size +=3D PAGE_SIZE; =20 - va =3D alloc_vmap_area(size, align, start, end, node, gfp_mask); + va =3D alloc_vmap_area(size, align, start, end, node, gfp_mask, 0); if (IS_ERR(va)) { kfree(area); return NULL; --=20 2.34.1 From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0324C64EC3 for ; Mon, 6 Feb 2023 08:42:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230038AbjBFIl6 (ORCPT ); Mon, 6 Feb 2023 03:41:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229993AbjBFIln (ORCPT ); Mon, 6 Feb 2023 03:41:43 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 550F217145 for ; Mon, 6 Feb 2023 00:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672853; 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=qDthkt1yrsdVPAFblgfFdo4HNws2a1WpfRKMjlx3T68=; b=Wza+ghHrUUAPL77B6S7ekG/Bs4SQET6zBoV9ksNqbqhVYZeQbTqlYddLI8b6kxD67tl3qx juYDxW2SIeavfYtunI2xPtTp040wTy+4H6FPKanNr+p2r+/hHNTkgFQJo0lnXPt2K+rjkh 9/nCVVqG/wnJesAXWn9KEdlwF5Qm5BI= 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-620-GfzowxhZMZyVQncuaXs6Yw-1; Mon, 06 Feb 2023 03:40:42 -0500 X-MC-Unique: GfzowxhZMZyVQncuaXs6Yw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2F7C5858F0E; Mon, 6 Feb 2023 08:40:42 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 14BF52166B2A; Mon, 6 Feb 2023 08:40:37 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Date: Mon, 6 Feb 2023 16:40:16 +0800 Message-Id: <20230206084020.174506-4-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Currently, vread can read out vmalloc areas which is associated with a vm_struct. While this doesn't work for areas created by vm_map_ram() interface because it doesn't have an associated vm_struct. Then in vread(), these areas are all skipped. Here, add a new function vmap_ram_vread() to read out vm_map_ram areas. The area created with vmap_ram_vread() interface directly can be handled like the other normal vmap areas with aligned_vread(). While areas which will be further subdivided and managed with vmap_block need carefully read out page-aligned small regions and zero fill holes. Reported-by: Stephen Brennan Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes Tested-by: Stephen Brennan --- mm/vmalloc.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 81 insertions(+), 7 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ab4825050b5c..4bb78ebd70f6 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3544,6 +3544,68 @@ static int aligned_vread(char *buf, char *addr, unsi= gned long count) return copied; } =20 +static void vmap_ram_vread(char *buf, char *addr, int count, unsigned long= flags) +{ + char *start; + struct vmap_block *vb; + unsigned long offset; + unsigned int rs, re, n; + + /* + * If it's area created by vm_map_ram() interface directly, but + * not further subdividing and delegating management to vmap_block, + * handle it here. + */ + if (!(flags & VMAP_BLOCK)) { + aligned_vread(buf, addr, count); + return; + } + + /* + * Area is split into regions and tracked with vmap_block, read out + * each region and zero fill the hole between regions. + */ + vb =3D xa_load(&vmap_blocks, addr_to_vb_idx((unsigned long)addr)); + if (!vb) + goto finished; + + spin_lock(&vb->lock); + if (bitmap_empty(vb->used_map, VMAP_BBMAP_BITS)) { + spin_unlock(&vb->lock); + goto finished; + } + for_each_set_bitrange(rs, re, vb->used_map, VMAP_BBMAP_BITS) { + if (!count) + break; + start =3D vmap_block_vaddr(vb->va->va_start, rs); + while (addr < start) { + if (count =3D=3D 0) + goto unlock; + *buf =3D '\0'; + buf++; + addr++; + count--; + } + /*it could start reading from the middle of used region*/ + offset =3D offset_in_page(addr); + n =3D ((re - rs + 1) << PAGE_SHIFT) - offset; + if (n > count) + n =3D count; + aligned_vread(buf, start+offset, n); + + buf +=3D n; + addr +=3D n; + count -=3D n; + } +unlock: + spin_unlock(&vb->lock); + +finished: + /* zero-fill the left dirty or free regions */ + if (count) + memset(buf, 0, count); +} + /** * vread() - read vmalloc area in a safe way. * @buf: buffer for reading data @@ -3574,7 +3636,7 @@ long vread(char *buf, char *addr, unsigned long count) struct vm_struct *vm; char *vaddr, *buf_start =3D buf; unsigned long buflen =3D count; - unsigned long n; + unsigned long n, size, flags; =20 addr =3D kasan_reset_tag(addr); =20 @@ -3595,12 +3657,21 @@ long vread(char *buf, char *addr, unsigned long cou= nt) if (!count) break; =20 - if (!va->vm) + vm =3D va->vm; + flags =3D va->flags & VMAP_FLAGS_MASK; + /* + * VMAP_BLOCK indicates a sub-type of vm_map_ram area, need + * be set together with VMAP_RAM. + */ + WARN_ON(flags =3D=3D VMAP_BLOCK); + + if (!vm && !flags) continue; =20 - vm =3D va->vm; - vaddr =3D (char *) vm->addr; - if (addr >=3D vaddr + get_vm_area_size(vm)) + vaddr =3D (char *) va->va_start; + size =3D vm ? get_vm_area_size(vm) : va_size(va); + + if (addr >=3D vaddr + size) continue; while (addr < vaddr) { if (count =3D=3D 0) @@ -3610,10 +3681,13 @@ long vread(char *buf, char *addr, unsigned long cou= nt) addr++; count--; } - n =3D vaddr + get_vm_area_size(vm) - addr; + n =3D vaddr + size - addr; if (n > count) n =3D count; - if (!(vm->flags & VM_IOREMAP)) + + if (flags & VMAP_RAM) + vmap_ram_vread(buf, addr, n, flags); + else if (!(vm->flags & VM_IOREMAP)) aligned_vread(buf, addr, n); else /* IOREMAP area is treated as memory hole */ memset(buf, 0, n); --=20 2.34.1 From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12EFFC61DA4 for ; Mon, 6 Feb 2023 08:41:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229826AbjBFIlt (ORCPT ); Mon, 6 Feb 2023 03:41:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229735AbjBFIlh (ORCPT ); Mon, 6 Feb 2023 03:41:37 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E88B18160 for ; Mon, 6 Feb 2023 00:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672850; 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=sogBXQhtIR7vZucKmKsbqW5MbruC+cj6YTx4qBV1xD0=; b=BayCutNNAaQn2i7aCQpY5iHEDjg1CYaf0ge3n6bh5blTeSJgo53psy/rGF6Gju5QZzJB5A VjdxNmUZT7mbZFyCYWV/CcVtot6OJjAhy4/BILzMU0zf/q0huQteM4K/9zS9mEZ6tjMqRf t9AeKjU14x2j3BO7mWc7L676B3IfEXo= 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-608-T_gvIW3LMJm5jXCXZZ71cw-1; Mon, 06 Feb 2023 03:40:47 -0500 X-MC-Unique: T_gvIW3LMJm5jXCXZZ71cw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 28E7D80D0ED; Mon, 6 Feb 2023 08:40:47 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0267E2166B2A; Mon, 6 Feb 2023 08:40:42 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 4/7] mm/vmalloc: explicitly identify vm_map_ram area when shown in /proc/vmcoreinfo Date: Mon, 6 Feb 2023 16:40:17 +0800 Message-Id: <20230206084020.174506-5-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Now, by marking VMAP_RAM in vmap_area->flags for vm_map_ram area, we can clearly differentiate it with other vmalloc areas. So identify vm_map_area area by checking VMAP_RAM of vmap_area->flags when shown in /proc/vmcoreinfo. Meanwhile, the code comment above vm_map_ram area checking in s_show() is not needed any more, remove it here. Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes --- mm/vmalloc.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 4bb78ebd70f6..dea76e73e57c 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4233,14 +4233,11 @@ static int s_show(struct seq_file *m, void *p) =20 va =3D list_entry(p, struct vmap_area, list); =20 - /* - * s_show can encounter race with remove_vm_area, !vm on behalf - * of vmap area is being tear down or vm_map_ram allocation. - */ if (!va->vm) { - seq_printf(m, "0x%pK-0x%pK %7ld vm_map_ram\n", - (void *)va->va_start, (void *)va->va_end, - va->va_end - va->va_start); + if (va->flags & VMAP_RAM) + seq_printf(m, "0x%pK-0x%pK %7ld vm_map_ram\n", + (void *)va->va_start, (void *)va->va_end, + va->va_end - va->va_start); =20 goto final; } --=20 2.34.1 From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A179C61DA4 for ; Mon, 6 Feb 2023 08:41:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230016AbjBFIln (ORCPT ); Mon, 6 Feb 2023 03:41:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229940AbjBFIlf (ORCPT ); Mon, 6 Feb 2023 03:41:35 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BBC918142 for ; Mon, 6 Feb 2023 00:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672854; 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=hiVEWJoEN/c7PwG6FQD6hYWxpoLbbmsKmDjpAMaWIR0=; b=C1ZgDxm17Z6zTPM/85h3MgVE+xoaPAbEDaoR6NyNzn1xf8PYLZDADxhPDQsPnCw2KA8FtX Y28YA/7xbOBrZLDdkfddSWU+LY77+IQJtrZ6XkIdZnK6AAjTiXbP5LTQtjR4+Zyfj3ZGlF HbGi0pNIxWXsnOSCMWILxAs3L1tCFSY= 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-622-GSAZ0BOoM8aVUFekIGNdrA-1; Mon, 06 Feb 2023 03:40:52 -0500 X-MC-Unique: GSAZ0BOoM8aVUFekIGNdrA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 120E687B2A0; Mon, 6 Feb 2023 08:40:52 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id DFD372166B2A; Mon, 6 Feb 2023 08:40:47 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 5/7] mm/vmalloc: skip the uninitilized vmalloc areas Date: Mon, 6 Feb 2023 16:40:18 +0800 Message-Id: <20230206084020.174506-6-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" For areas allocated via vmalloc_xxx() APIs, it searches for unmapped area to reserve and allocates new pages to map into, please see function __vmalloc_node_range(). During the process, flag VM_UNINITIALIZED is set in vm->flags to indicate that the pages allocation and mapping haven't been done, until clear_vm_uninitialized_flag() is called to clear VM_UNINITIALIZED. For this kind of area, if VM_UNINITIALIZED is still set, let's ignore it in vread() because pages newly allocated and being mapped in that area only contains zero data. reading them out by aligned_vread() is wasting time. Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes Reviewed-by: Uladzislau Rezki (Sony) --- mm/vmalloc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index dea76e73e57c..8037527774db 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3668,6 +3668,11 @@ long vread(char *buf, char *addr, unsigned long coun= t) if (!vm && !flags) continue; =20 + if (vm && (vm->flags & VM_UNINITIALIZED)) + continue; + /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */ + smp_rmb(); + vaddr =3D (char *) va->va_start; size =3D vm ? get_vm_area_size(vm) : va_size(va); =20 --=20 2.34.1 From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FEBDC64EC4 for ; Mon, 6 Feb 2023 08:42:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229731AbjBFImF (ORCPT ); Mon, 6 Feb 2023 03:42:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230015AbjBFIln (ORCPT ); Mon, 6 Feb 2023 03:41:43 -0500 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 662F51814B for ; Mon, 6 Feb 2023 00:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672858; 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=lNZtN3K6Lqx2kVVKvoFNyaccpQbarea9cnt235tEpuI=; b=IeHLbeziJPxu9KBigmdys2HrjlLDfJuZF7844uXDHAZqturcQ5ZPTXhZ8DykOCTbI8pUhz O2avyDvfNCdVBRwpuLrZytTgtrLXH3obGnP8ASBkjOs73tm4XnkqTF/b4QTVza6T6DYJSa h+L76huWh+H9rkkP9ALo2CBYxWO9kL0= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-491-Ny2Zzr1OOLWi1hrheDXFew-1; Mon, 06 Feb 2023 03:40:57 -0500 X-MC-Unique: Ny2Zzr1OOLWi1hrheDXFew-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A3AE73C025BC; Mon, 6 Feb 2023 08:40:56 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id CAA0C2166B29; Mon, 6 Feb 2023 08:40:52 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 6/7] powerpc: mm: add VM_IOREMAP flag to the vmalloc area Date: Mon, 6 Feb 2023 16:40:19 +0800 Message-Id: <20230206084020.174506-7-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Currently, for vmalloc areas with flag VM_IOREMAP set, except of the specific alignment clamping in __get_vm_area_node(), they will be 1) Shown as ioremap in /proc/vmallocinfo; 2) Ignored by /proc/kcore reading via vread() So for the io mapping in ioremap_phb() of ppc, we should set VM_IOREMAP in flag to make it handled correctly as above. Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes Reviewed-by: Uladzislau Rezki (Sony) --- arch/powerpc/kernel/pci_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c index 0c7cfb9fab04..fd42059ae2a5 100644 --- a/arch/powerpc/kernel/pci_64.c +++ b/arch/powerpc/kernel/pci_64.c @@ -132,7 +132,7 @@ void __iomem *ioremap_phb(phys_addr_t paddr, unsigned l= ong size) * address decoding but I'd rather not deal with those outside of the * reserved 64K legacy region. */ - area =3D __get_vm_area_caller(size, 0, PHB_IO_BASE, PHB_IO_END, + area =3D __get_vm_area_caller(size, VM_IOREMAP, PHB_IO_BASE, PHB_IO_END, __builtin_return_address(0)); if (!area) return NULL; --=20 2.34.1 From nobody Sat Sep 13 00:24:23 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD6D7C05027 for ; Mon, 6 Feb 2023 08:42:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229523AbjBFImU (ORCPT ); Mon, 6 Feb 2023 03:42:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230089AbjBFIl4 (ORCPT ); Mon, 6 Feb 2023 03:41:56 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65C0318161 for ; Mon, 6 Feb 2023 00:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675672863; 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=yf8UeWDRzlFUhfaCSIXW0vSnsYH1u1H+pSaVUFMvrEs=; b=gcuyEw2oezmiLmw34rfCVgPahCCjLNavr4YYrTLgr/bSuKVenyNj5JJniWGtL1GHFYcbln vlUE7jZa1qpplkp5h9gEtY0tY94vR2Gjgx4NniwIlUy84RsG9lAKwtk2j1e2DqZvekYUgJ Lft5yQTFmAcMEisWDUYXs1TQrKPlyQ4= 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-128-6zunQOeMP6WEHO3AFKzI_w-1; Mon, 06 Feb 2023 03:41:01 -0500 X-MC-Unique: 6zunQOeMP6WEHO3AFKzI_w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 54393100F907; Mon, 6 Feb 2023 08:41:01 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6B3632166B29; Mon, 6 Feb 2023 08:40:57 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, lstoakes@gmail.com, error27@gmail.com, Baoquan He Subject: [PATCH v5 7/7] sh: mm: set VM_IOREMAP flag to the vmalloc area Date: Mon, 6 Feb 2023 16:40:20 +0800 Message-Id: <20230206084020.174506-8-bhe@redhat.com> In-Reply-To: <20230206084020.174506-1-bhe@redhat.com> References: <20230206084020.174506-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Currently, for vmalloc areas with flag VM_IOREMAP set, except of the specific alignment clamping in __get_vm_area_node(), they will be 1) Shown as ioremap in /proc/vmallocinfo; 2) Ignored by /proc/kcore reading via vread() So for the ioremap in __sq_remap() of sh, we should set VM_IOREMAP in flag to make it handled correctly as above. Signed-off-by: Baoquan He Reviewed-by: Lorenzo Stoakes Reviewed-by: Uladzislau Rezki (Sony) --- arch/sh/kernel/cpu/sh4/sq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sh/kernel/cpu/sh4/sq.c b/arch/sh/kernel/cpu/sh4/sq.c index a76b94e41e91..27f2e3da5aa2 100644 --- a/arch/sh/kernel/cpu/sh4/sq.c +++ b/arch/sh/kernel/cpu/sh4/sq.c @@ -103,7 +103,7 @@ static int __sq_remap(struct sq_mapping *map, pgprot_t = prot) #if defined(CONFIG_MMU) struct vm_struct *vma; =20 - vma =3D __get_vm_area_caller(map->size, VM_ALLOC, map->sq_addr, + vma =3D __get_vm_area_caller(map->size, VM_IOREMAP, map->sq_addr, SQ_ADDRMAX, __builtin_return_address(0)); if (!vma) return -ENOMEM; --=20 2.34.1