From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE434C61DA4 for ; Thu, 2 Feb 2023 03:20:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7432B6B0073; Wed, 1 Feb 2023 22:20:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F2A86B0075; Wed, 1 Feb 2023 22:20:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56EE36B0078; Wed, 1 Feb 2023 22:20:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 46EA16B0073 for ; Wed, 1 Feb 2023 22:20:19 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 16AA5A0340 for ; Thu, 2 Feb 2023 03:20:19 +0000 (UTC) X-FDA: 80420898558.28.DF8007A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 04E4612000F for ; Thu, 2 Feb 2023 03:20:16 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fokFN2Jx; spf=pass (imf29.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675308017; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rK7R8Ymf//RLaf8YqF06g2e/AYVjMdAxmOF83wfnLdo=; b=B3QGrBh4JWe6TxgvAbeosWstIQ9AZgaBz4kPXQBXN7wZT7pGk8J2MyJtEeu/w6JBpulk3U cOkpHCdNxsY76Ums4BnkfhTpxBS7Mh3+mwi3znlGRSfQdP8hT+UVqTCAYAyPIjhnGDeLJK F5UhSgjfEzsT66q675x/Qs3iRLxrmFg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fokFN2Jx; spf=pass (imf29.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675308017; a=rsa-sha256; cv=none; b=N/sDLFEPjsqXnbPfP2wDtxi1pnDKOdMF+rLglyLrziXghiuGRShytjNCugle3Mxrd5Zg92 jQdz2/KC1TdxuU4dwVfMtfBZ1jGrqumPqOAf1uZ1w2LTgJLhdseBjD8k7eHITQiSFGF3cs ylyP+QAwjVtBOUmo2hoIPGTtE+SVyj4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675308016; 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: in-reply-to:in-reply-to:references:references; bh=rK7R8Ymf//RLaf8YqF06g2e/AYVjMdAxmOF83wfnLdo=; b=fokFN2JxSJjYmCzNHZIyAW8OhAFpBypgMk69arnSefOXDnhPFggCs6hKgL+lJr8osQJg0f 9P0gWqGLz5dEKll6nxQS/LhZu1I7RfLP0gao+K/N9eQDw5vlkE0Jl+H6OgSMg2+QZd0bq2 AMIpRvWYXPuDokByu3VMD/o4rVrOrhw= 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-295-eL-bS1ooPSu4NaxsFXnbeA-1; Wed, 01 Feb 2023 22:20:13 -0500 X-MC-Unique: eL-bS1ooPSu4NaxsFXnbeA-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 617F7802314; Thu, 2 Feb 2023 03:20:12 +0000 (UTC) Received: from localhost (ovpn-12-116.pek2.redhat.com [10.72.12.116]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BB31404BEC0; Thu, 2 Feb 2023 03:20:10 +0000 (UTC) Date: Thu, 2 Feb 2023 11:20:07 +0800 From: Baoquan He To: Lorenzo Stoakes Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, willy@infradead.org, hch@infradead.org, error27@gmail.com Subject: Re: [PATCH v4 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Message-ID: References: <20230201091339.61761-1-bhe@redhat.com> <20230201091339.61761-4-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 04E4612000F X-Stat-Signature: xfrwrf58ynhwo1uuzzwg6dc5ub94js97 X-HE-Tag: 1675308016-33529 X-HE-Meta: U2FsdGVkX19TPwUfnub3WZQ1wT6mxaJRaVaSt++9qAX9l7o/24x4L704stP09GyZNrgEG5JIkMDauL4BWy1+2rjqJLILd7s6ZZA+oeUCub26F9RwRxnc3LA37xPhVEAJy8I65ji+csfq15RN4hlY0OQ8Cbre+a68+aWC6B305qU7kY1Z+aEAGqB719M4L/MHrj6RVG6anNn4pbDKRVQhbM0r1axBQQDKZin6CC4bW/qG16ilMKBX8URhwClHgGjnIOV5OfCd60/7+FgVAnc3ctvk7lymdLubK9tqlNOdilVeotbw6HwW/313pEHVZ7ObUFvHj9WEkKcPiL96BROpSy/9uiFkVQ9WrykM5Mxuzc/ATN+Wbo/zR+lpm5oyNUOHEZfezgkoJ6r6w8jTfyBdj534VfOZ1/FXvxlUdk/MKJqksiF58GJ84+J0JuKw6NoWiTm6+WH+Bjuev1HhY2UKPm4qei75iQ54Wir0sM76+y0U4vM5e1j7C87Xg2OYWhzuzKalQDy6JFzewMRU6pgYFuw1iituNy3G1TKqMJoT1ObMVi1fryPGWOrSB9ESlad+VYEaldw9N5azvbekz1tRvtWnxb9YQXTOZyaXb4sNVjfcZPeZ4ndT5RYMLznN6qsLrew99ACWBW5QLrcQVZnsPrdnnpPxy73xWRp2jf82Bo+fdKcCGEfx6LiD8qK/YZOmR+DOXsLM+TCnhdbOaHII3UcfWyugse1gyXrwZD0mEpVnHgeD1koFg6oGBWc4ZhS1h0pZrbClFba5UyqegKNP6o5O6vFFf0tk2wYxPqMq/Gav1IaNVXkFtB1Yg2HXDFhymdlpW0bJa3jevvW2lT/w/jwp2mYoggRQXzHjxzk1uL5zABv12VDXXWkv7rjM0Tj8zKXYTW3bUDrvZYm6vh5v8tQ8iYRpuNgt9uHfeXFvgEMh1CGLsPiqdJ+aj8NbXWMhaf91A70EQRkGP13vIEi ku6ijJ2g 5Qe8U6ann3PHmZEmg0ETwjQZcBPZAcApPsvIwzcGNNQLWIvxPOoYGzwV7r9MHMCIQLwqu46XgQXlydJUKZzBO7QNrpRBqIvevWumRmufH6HYSR0f/Fqo6WFB5TXiFYEmGKYyurgRz9Y30ORUQoBfrjfem6MyRKlyVxFsQj19RVIirIYqemhQZCOuvoZbjO/Y/IwN2UOWnqU0iUafLDWAxX9HpALWE8F8wn79nynD+HgTB8AYJa4R6gX5I7lAH+L9PjNGsj/cprk7qqeLq65RzyauVW+hST9icW/zsLyoq0bLT70zF7xADySb37Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 02/01/23 at 08:16pm, Lorenzo Stoakes wrote: > On Wed, Feb 01, 2023 at 05:13:35PM +0800, Baoquan He wrote: > > 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. > > > > Signed-off-by: Baoquan He > > --- > > mm/vmalloc.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++----- > > 1 file changed, 80 insertions(+), 7 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index ab4825050b5c..5a3ea6cb7ec2 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -3544,6 +3544,67 @@ static int aligned_vread(char *buf, char *addr, unsigned long count) > > return copied; > > } > > > > +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 = 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 = vmap_block_vaddr(vb->va->va_start, rs); > > + while (addr < start) { > > + if (count == 0) > > + break; > > Bit pedantic, but you're using the `if (!count)` form of checking whether it's > zero above, but here you explicitly check it, would be good to keep both consistent. Yeah, sounds good. Will change. > > Given you're checking here, perhaps you could simply drop the previous check? Well, maybe no. The previous "if (!count)" is checking if count is 0 after the 'count -=n;' line at the end of the for_each loop. While this "if (count == 0)" is checking if count is 0 after 'count--;' at the end of while loop. Not sure if I got your point. > > > + *buf = '\0'; > > + buf++; > > + addr++; > > + count--; > > + } > > + /*it could start reading from the middle of used region*/ > > + offset = offset_in_page(addr); > > + n = ((re - rs + 1) << PAGE_SHIFT) - offset; > > + if (n > count) > > + n = count; > > + aligned_vread(buf, start+offset, n); > > + > > + buf += n; > > + addr += n; > > + count -= n; > > + } > > + 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 +3635,7 @@ long vread(char *buf, char *addr, unsigned long count) > > struct vm_struct *vm; > > char *vaddr, *buf_start = buf; > > unsigned long buflen = count; > > - unsigned long n; > > + unsigned long n, size, flags; > > > > addr = kasan_reset_tag(addr); > > > > @@ -3595,12 +3656,21 @@ long vread(char *buf, char *addr, unsigned long count) > > if (!count) > > break; > > > > - if (!va->vm) > > + vm = va->vm; > > + flags = 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 == VMAP_BLOCK); > > + > > + if (!vm && !flags) > > continue; > > > > - vm = va->vm; > > - vaddr = (char *) vm->addr; > > - if (addr >= vaddr + get_vm_area_size(vm)) > > + vaddr = (char *) va->va_start; > > + size = vm ? get_vm_area_size(vm) : va_size(va); > > + > > + if (addr >= vaddr + size) > > continue; > > while (addr < vaddr) { > > if (count == 0) > > @@ -3610,10 +3680,13 @@ long vread(char *buf, char *addr, unsigned long count) > > addr++; > > count--; > > } > > - n = vaddr + get_vm_area_size(vm) - addr; > > + n = vaddr + size - addr; > > if (n > count) > > n = 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); > > -- > > 2.34.1 > > > > Other than the nit, feel free to add:- > > Reviewed-by: Lorenzo Stoakes >