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 AAF97C636D4 for ; Wed, 1 Feb 2023 20:16:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 018FB6B0072; Wed, 1 Feb 2023 15:16:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F0B4E6B0074; Wed, 1 Feb 2023 15:16:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DABCC6B0075; Wed, 1 Feb 2023 15:16:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CA82F6B0072 for ; Wed, 1 Feb 2023 15:16:29 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 920EB120E7C for ; Wed, 1 Feb 2023 20:16:29 +0000 (UTC) X-FDA: 80419830498.15.434EBF1 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf11.hostedemail.com (Postfix) with ESMTP id AB61140006 for ; Wed, 1 Feb 2023 20:16:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fpKWon3c; spf=pass (imf11.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675282587; 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=q57ln7oTT4qVotRIsJQ/UUUBpBA8wVo803kMrdqxSLk=; b=j0YolVMrjjv/OUtO/pSSfB/hySb1RX631zNfw5I62MVblQHzWY+loJCCbNdCow1H8WBMAt NhgDapcs2plin1YRghmUYFcnB4ZQ+nFEWz4c4pn9v2NrqFzJvbNhWHtywb6LKQXE5r4RqK DSUCQAHl/enKg5Ik/LTzb22H4rDVd5o= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fpKWon3c; spf=pass (imf11.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675282587; a=rsa-sha256; cv=none; b=NEqhdtp7MpHEcHeUPHxzmpoNWSUJNB6JFkLP9ktW+NAE6zfTweH61yv7G3ca0LkbUH5peU zlhuMc17HB0yz/Qr7Li4GBK0s+2uplrbQTrZo+CdwDySAxHX1zUgeqzKhepWxY02oR5vBV 6uu1gcmgsW6zRIc1PI2T87Kxu17G510= Received: by mail-wm1-f43.google.com with SMTP id q8so13538914wmo.5 for ; Wed, 01 Feb 2023 12:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=q57ln7oTT4qVotRIsJQ/UUUBpBA8wVo803kMrdqxSLk=; b=fpKWon3cofKU+VuXd+KGExnWbE9ugoZ+ImQSgDmMdfXpe3DAZIy5RIo9Gu+ZQFNuzH YSJwl41KXiMm9hVaI6RWc6kDtAQPdgcFslcI+OBZ8Lh+8DZvuqIGJ2+ZWR7Xe5nHIwwT 4K0KpsBbYJrkIyFXF0/G6L2XFG7mxZ1CXs2nguAUiaoxFT+gj3gGQ42hqH5MbOqggcrl qLkV0KM2Y9c+rAv8vEjOUENIrP45M2bxA0G1Z3L2m/O4n5mOu6Tk2fjeFL0jZ0ZCxH2d 8yOWSpitF7Rt4QYxxfMfX1eYlGnqXaqGP5/bZ413Aqo5ABGjd7ewwmiphMsbTBMhM9xG 9+vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q57ln7oTT4qVotRIsJQ/UUUBpBA8wVo803kMrdqxSLk=; b=qAcujFcbDTX6cPrZq8Y+8YMCYV2+/73JSETz8KwdgJvEz7NGDU1O0hSFptlavjkdPz YwTqZn30Y0KrGUVIXScpF5NaWb1COs7h4yebPsBHNQqhaE3+n7BDAe8f0A8Fy7ev4dk3 UTIOh8xc0VMvxSBB9SFHwRg8NtdLwsBxfUQHjrCTc3hPm0jq0X/5hZnh1C7ZssHcqSVt CAWMIidSH91Xj8fhW3HkJ8KG+MSK69xqLjGIBqO79rty749HCmTvVFaA1vN59u8ada4q vAdknnsdlHErTsxdMudlgXXImYVorJuDBwxdmNZrFbtEcFugpFyrYLHCckCiDfQ30yD5 40Gw== X-Gm-Message-State: AO0yUKXYz23rzgM8bnYGCIAwVwBj6aknFhG45DmZZhWlYjKzthbLjxst h+7SY7HOkFaRl6+2FaXiilk= X-Google-Smtp-Source: AK7set//F6ZawrhUzuTjH86mOLyXvSXwT+XRaOBN+l1u0H5aZYonxsLNXz7wR8XfOgxATfiaBk2rXw== X-Received: by 2002:a05:600c:35d5:b0:3dc:443e:3a8b with SMTP id r21-20020a05600c35d500b003dc443e3a8bmr3459642wmq.16.1675282586058; Wed, 01 Feb 2023 12:16:26 -0800 (PST) Received: from localhost (host86-164-169-89.range86-164.btcentralplus.com. [86.164.169.89]) by smtp.gmail.com with ESMTPSA id k27-20020a05600c081b00b003de77597f16sm2634549wmp.21.2023.02.01.12.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 12:16:24 -0800 (PST) Date: Wed, 1 Feb 2023 20:16:24 +0000 From: Lorenzo Stoakes To: Baoquan He 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: <20230201091339.61761-4-bhe@redhat.com> X-Rspamd-Queue-Id: AB61140006 X-Stat-Signature: kkd54mdw5zf4waum4g6sgkzpskk4dyjg X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675282587-568232 X-HE-Meta: U2FsdGVkX19yYdqYjYUL4iS95EiSiT903b2aE+F3/ZTL/O0kLSzISTyKTHtFRdkzZW5U0Qn6raKUNhLaXqlhU6cLig6Bnoj2TbQKg4QJhcV2TlJ28ybwOHGYXgCPThrCmkUsjVcMJzMsGVzVXB6hiU7tHAEgWQzWyjWfzxYs5KZpVv7N/WqEoWbj73dPFrazg1ZKnoGfjZMkC7KmjLgskvE+Hd6RHY+MjNPm8NjungiXZp/EcYILZTXI4P8v1Nc/El9V0S6XjOHyUFseBdI/1+wYuM3Pa5mGDt+x0o4hUSb4G+EQRKWzstiQdpuYYEcTOrBCNR41+hKYFbJUi394zH7HacDbOUIhg3973UvPHTCiJkDneY5U3kYDofwNcDqAynBq9u5/V3NM4fA/TTW+9Tftvd7IpZDaUEX60oaaMICWJa5tvJ+HySSjoPuvl8mcCiybBk8VGTOcgd1Wj04jPCDMpjUcwwDzS7wQabDIABHkggofBHGUmkxbsTlFrNrb6TyVnBXqa3mkg+hcFOGCIjHNpNpKlnBYse/eqFF4s25s5B2/C/Dk7dY+UcWBo8QIfL+rY55Q3nuNaFauYHy2tjDMb2LczXtmAxl1rcL62W7aN2H6bttl/7KRnLUEkT5smKHVMXapCABkqEHXov1zW9+SLIMsPjKLHDMqo+Bg0JjHo0WqNQsYfSMgmfhcD6ITYVbasOgIs2hCZps8wlMcYJKGWHhc92+EjdygpjBvg7Xp9uAoD7Fqxw7J57r7GF51C5mB3cwt832YdlD72Kz1RWZX1ild9F/Rm6RzBk1O7mRYpIHBwoxJh6VGAjcwmV2oi0yq8O17LV3vkZD7VIWJsSMMVuyXFdYudUjWsF8W6j6m5LLbRsoPLuQSzmgshcL+a4bzRASN2WjTB13Ih05V/0TprJ3eRFy2GE59G+at7scCZYOa9lPjMB+N02zHy7f+E9UOJgHzVu1mURcbYdx 3LXxu/cX Ucz8bZAJOFYylm6i9FV9I0AunqFt87xMfdQXNmUqgoe7msifRTC3ZinkinCyx8XvIjEc/MkN7xJdWs1HncKfxU/oqYplqrWS9ZViZc5EPpRCk+ln3U7ZG4NVS4d9W7jajTpqbqVyx6+RsuEs9kJrg0G72/lurrFnZtVM3XcT+JdH8OjE8HRnOUo75ViKc2crquR64eKszLahKEJyzybiXgttARBls3Tj6NsSOhgvNRjy7tQHlSim5bE6+4Br5UbnZJeiVDqBok+beG6UfwiUXDkMUn03s0G/8mOFMJGVxjG+1OMeFEzTcHCix3uTP63hwr9gWFJS7vMphdJGz+NNlmhmXCA0CoRkz/+F9SNW765V6Ai3zIc0njO8rGRjpLynEzb0V4DJbBMrnsVCeUJkwqPAxtPZFk7H9DlTjg7CkC8nBkyjQvwX3TnHPQGy3jRu6iUBZQypzrR+G8HenGmQFD/+Hsh3AoouE0Tx7ZPLY2ZM8haCqKhXILwl+nGHlPRSuZwSc 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 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. Given you're checking here, perhaps you could simply drop the previous check? > + *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