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 2919BC433FE for ; Thu, 17 Nov 2022 06:49:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AD4F8E0002; Thu, 17 Nov 2022 01:49:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 95D7F6B007D; Thu, 17 Nov 2022 01:49:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8253F8E0002; Thu, 17 Nov 2022 01:49:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 70D686B007B for ; Thu, 17 Nov 2022 01:49:14 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3B43380873 for ; Thu, 17 Nov 2022 06:49:14 +0000 (UTC) X-FDA: 80142007428.26.6049925 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf10.hostedemail.com (Postfix) with ESMTP id 93B5BC000A for ; Thu, 17 Nov 2022 06:49:13 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A8520B81F5E for ; Thu, 17 Nov 2022 06:49:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76222C4347C for ; Thu, 17 Nov 2022 06:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668667750; bh=08u/sTGELHIpjr9mtQ8XZ3j+lFZpqrOGj8F/MH2k9t8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VH6+KsLrRg74wODo7HspmCSAhgOJKUrOFzk3zQ/sEOTWOCTqBdH/650PNa/iPH5FV nP/asPvDuFVLMHoTRpFDj/c8hWCtsoEZCIi63PLkdGxOmXJ98fJRjsRE6VUdnLLl76 miCX0+5MX+R1u/ILGtvY9JaNuFuV7YCTrD4rZmCcADlhriZDiGbfOcDt5PNiiPXU+M qIWtnTieYxdWZ60OBilKRfC5bWleW/XcpnnK3SR911pfV+3xi53LbG8idZuS4jT+zu MiLO5wU5aQbs2ONnBaSAT9gOy+T27X0TzNjjWlGoeIR5mtjbbrep1S2VosAuD1KHNR t/G/K7fBwVHLA== Received: by mail-ed1-f51.google.com with SMTP id x102so1254817ede.0 for ; Wed, 16 Nov 2022 22:49:10 -0800 (PST) X-Gm-Message-State: ANoB5pn+kmwBU2NtH7Kb+VA96wyftE15jC6HO3irbKGYWZC4rX7fZNKU RpiDjgoppGWjuNmCPps9rgIlUXu7HBQPjDUHrzU= X-Google-Smtp-Source: AA0mqf4MXzYIzmYW4qHTtMPMheKCJmsww+V+IW07ffCicoXtzzcn9lfzoNLP+AQWXATW1mFbdWw1sJuXcGqwYFR4U50= X-Received: by 2002:a50:fa83:0:b0:461:565e:8779 with SMTP id w3-20020a50fa83000000b00461565e8779mr956341edr.387.1668667748735; Wed, 16 Nov 2022 22:49:08 -0800 (PST) MIME-Version: 1.0 References: <20221117010621.1891711-1-song@kernel.org> <20221117010621.1891711-2-song@kernel.org> In-Reply-To: From: Song Liu Date: Wed, 16 Nov 2022 22:48:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v3 1/6] vmalloc: introduce execmem_alloc, execmem_free, and execmem_fill To: Luis Chamberlain Cc: bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org, peterz@infradead.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668667753; a=rsa-sha256; cv=none; b=kgoxRz+ZOmvJiAoS56Uz2/DDRXFXUsCLd2s1DjPQRK7ieh4EirAbbhlMDWDK6z/OK0P1JO DOY5PkfqYlgVZ0ilqAwYmegE1vkHqnORERdAPBLpBZBD/T5rdkYhySu/mvP0A8POkJ8ZYQ QoMF6O3pQT0o+RpG/xcW0Re94R3Rfgo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VH6+KsLr; spf=pass (imf10.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668667753; 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=Cxh7apCWhxmwpLI3T2sS8/v1MEIXCAq49zK0vJxOHJM=; b=yhrfCNGzLqYWZaHngG7HIzFItt+56NPWQKYIx7L69KvkoxwF0zAs1OVhovOU9JZHN33Jun 7ByVcjZUrkkW1jXUz3RxazAVmJSmkm6Ya2foDg0DydGtZpusXjo6zmApviPMDILCR/NL04 2rZE4ipuE6S7NtjExuGOuIQpnjC8ex8= X-Stat-Signature: ex7q67ag8dde3i9rq8ex3dndrxq3fxhh X-Rspamd-Queue-Id: 93B5BC000A Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VH6+KsLr; spf=pass (imf10.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668667753-284414 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, Nov 16, 2022 at 5:36 PM Luis Chamberlain wrote: > > On Wed, Nov 16, 2022 at 05:06:16PM -0800, Song Liu wrote: > > +static void move_vmap_to_free_text_tree(void *addr) > > +{ > > + struct vmap_area *va; > > + > > + /* remove from vmap_area_root */ > > + spin_lock(&vmap_area_lock); > > + va = __find_vmap_area((unsigned long)addr, &vmap_area_root); > > + if (WARN_ON_ONCE(!va)) { > > + spin_unlock(&vmap_area_lock); > > + return; > > + } > > + unlink_va(va, &vmap_area_root); > > + spin_unlock(&vmap_area_lock); > > + > > + /* make the memory RO+X */ > > + memset(addr, 0, va->va_end - va->va_start); > > + set_memory_ro(va->va_start, (va->va_end - va->va_start) >> PAGE_SHIFT); > > + set_memory_x(va->va_start, (va->va_end - va->va_start) >> PAGE_SHIFT); > > + > > + /* add to all_text_vm */ > > + va->vm->next = all_text_vm; > > + all_text_vm = va->vm; > > + > > + /* add to free_text_area_root */ > > + spin_lock(&free_text_area_lock); > > + merge_or_add_vmap_area_augment(va, &free_text_area_root, &free_text_area_list); > > + spin_unlock(&free_text_area_lock); > > +} > > <-- snip --> > > > +void *execmem_alloc(unsigned long size, unsigned long align) > > +{ > > + struct vmap_area *va, *tmp; > > + unsigned long addr; > > + enum fit_type type; > > + int ret; > > + > > + va = kmem_cache_alloc_node(vmap_area_cachep, GFP_KERNEL, NUMA_NO_NODE); > > + if (unlikely(!va)) > > + return NULL; > > + > > +again: > > + preload_this_cpu_lock(&free_text_area_lock, GFP_KERNEL, NUMA_NO_NODE); > > + tmp = find_vmap_lowest_match(&free_text_area_root, size, align, 1, false); > > + > > + if (!tmp) { > > + unsigned long alloc_size; > > + void *ptr; > > + > > + spin_unlock(&free_text_area_lock); > > + > > + /* > > + * Not enough continuous space in free_text_area_root, try > > + * allocate more memory. The memory is first added to > > + * vmap_area_root, and then moved to free_text_area_root. > > + */ > > + alloc_size = roundup(size, PMD_SIZE * num_online_nodes()); > > + ptr = __vmalloc_node_range(alloc_size, PMD_SIZE, EXEC_MEM_START, > > + EXEC_MEM_END, GFP_KERNEL, PAGE_KERNEL, > > + VM_ALLOW_HUGE_VMAP | VM_NO_GUARD, > > + NUMA_NO_NODE, __builtin_return_address(0)); > > + if (unlikely(!ptr)) > > + goto err_out; > > + > > + move_vmap_to_free_text_tree(ptr); > > It's not perfectly clear to me how we know for sure nothing can take > this underneath our noses. This is because ptr points to vmap_area in vmap_area_* tree. It is only used by the user (this thread). It is like we know vmalloc memory will not go away until we call vfree on it. Does this make sense? Song