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 AE317C4345F for ; Thu, 18 Apr 2024 08:55:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C81116B0082; Thu, 18 Apr 2024 04:55:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2F9A6B0085; Thu, 18 Apr 2024 04:55:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD18C6B0087; Thu, 18 Apr 2024 04:55:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8DF536B0082 for ; Thu, 18 Apr 2024 04:55:23 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 328FDC12D4 for ; Thu, 18 Apr 2024 08:55:23 +0000 (UTC) X-FDA: 82022043726.28.BE24224 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf15.hostedemail.com (Postfix) with ESMTP id 6A122A0012 for ; Thu, 18 Apr 2024 08:55:21 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EzjuBgKX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713430521; 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=ATTOtpITJHTqXd4qITdiMR9j7i3v4ta7d8GuQUxjQKg=; b=JLZhmfiFDxk7E/q9ExQyALc9hUta5BpWl43gvF0MaDlRsLwWO7JU3aU8lIqxEgub6RPcmK KMTI0X3W2lSs3gbipxhdf5YdRz5UH1kP5b8fLyPiBSMOns2nIF3h8bL7KRJRM8G7ZcJr0v Jfr7mBlwuRrK35DdaPdrFWdIlhcRe3U= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EzjuBgKX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713430521; a=rsa-sha256; cv=none; b=xdMbiC4aPqr23WGfuiMAA0DK4DA6Cn+pMskUXwkGP8VTwuv9lcZHii9ITARmDu8dD8m5hL prFSeykzoRqgpFYpNyIteFr8sLd2GTrNa1C/LRJ65j2jd05aJJLItXA+Zxp75CWC40UFyz 5UKvAfB8kILOJKSLIJFSKuD1h3LiP6Y= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-518a56cdbcfso882788e87.2 for ; Thu, 18 Apr 2024 01:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713430519; x=1714035319; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=ATTOtpITJHTqXd4qITdiMR9j7i3v4ta7d8GuQUxjQKg=; b=EzjuBgKX1r2zELEr1h0m6oKUwkgIrv7bKyFTBIx11qS6CWWUpZP6kmoeOFlYetazei fQAfsYrPyvQ5dAPUXIQ7PfdZfhG1XDgszHbvsU9lq/2UcHW3moChQvCi5+a9UyldmKj6 N1EJLpECz/uqsmNw39huzfbvtKq82RB4ISuw9zts27m6+hpP43TszHsHKpyZ3iJTFFYh 1kSPbBeUprNLZw9nq59IIry3Xx7CD9DuEGDcgwN5voYy2p1hQOOsfos2nW/H9qxQtcJu d2HXehRqGCWFvfNZtDZpiHUcue5kPxQx4QDbmxQFA+vmI5Sest2RzereKJo19T02XK81 pV6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713430519; x=1714035319; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ATTOtpITJHTqXd4qITdiMR9j7i3v4ta7d8GuQUxjQKg=; b=ZBxHINK1xzXtKF6V4uzL2dH7rZa4l2RRmQ69a6aTg0u1B8uH1uPEYaQRA0bCiqO/QC RkgKkb4+dNLjk74UtAsmpkQ/GDqn79rlrubOT26Vk3AKj9bZ1rpa2LzAcKRkDDcGyfrs MIr6a9Elf93EaW/et0h5KMmy2/UlUhq53fhN+c219w8ff7zw/7UgvbF53gSmHqjb1vU0 RTZEPKAZH3TYdVamth2stvHa4waFUzN5mHTTxx8oLYYnHdm+qy8wh4QzrhIUcdjtnptm JjSUzf9dN8qu7LX4qUPNGOr7oTQAsSOxGFNC6PBFbIIiUgBG27Knmv8ssHgXDY/6Uig8 FHlw== X-Gm-Message-State: AOJu0YxjwTxC+XrlQKjDJqqpt0e1CL5lY7nEYJICy1tx6LX5z4NMnNs9 4m+ioorxluAtGCeyi2GLtiJMMlS9w+imfxxq6T9gpR/iIkFk6qE6 X-Google-Smtp-Source: AGHT+IHi5RkkzxI9vaTl7K0CKyoJi0lVLO/HprgvfOejQQ/ALyXGw9R75sHNZaJznI+ya9Itzk7Lcw== X-Received: by 2002:a19:434a:0:b0:516:cd71:9bb1 with SMTP id m10-20020a19434a000000b00516cd719bb1mr1195915lfj.38.1713430519072; Thu, 18 Apr 2024 01:55:19 -0700 (PDT) Received: from pc636 (host-90-233-210-75.mobileonline.telia.com. [90.233.210.75]) by smtp.gmail.com with ESMTPSA id p26-20020ac246da000000b005192bf678a3sm155253lfo.104.2024.04.18.01.55.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Apr 2024 01:55:18 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 18 Apr 2024 10:55:16 +0200 To: Maxwell Bland Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes Subject: Re: [PATCH 1/5] mm: allow arch refinement/skip for vmap alloc Message-ID: References: <20240416122254.868007168-1-mbland@motorola.com> <20240416122254.868007168-2-mbland@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240416122254.868007168-2-mbland@motorola.com> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6A122A0012 X-Stat-Signature: y65gwoq7w6rboxa3jf61kwpdour87iku X-HE-Tag: 1713430521-241582 X-HE-Meta: U2FsdGVkX19vG+KwaQg3mfBraOOMoTfO04JJ1SW9GMOGcj1udUDjYs34J37yLZmpq15ElaBe+Up3Z2z9yAPmVq6JqJb4PsdoC5cKWOy6LAC+GJrclnAHf/Gi56VVApBV5I8YWyiigzDKZDsGY8z02xEe2FXq2wZdnf8ljWoqim01Wzs+ElFfylrE+naDBAURWvgsflYPRQKiwcxulra6YBswpHzNixvvTjnc9MkoWhe/CNCdTE5CyJdAeNtB/HEmYtdl9ktj+Jb39V+SQcRRlTLCPUdihOQe8vsfQxBqM5umqD3r24x+H3n/fj17cdBOE7YdWLTQcQipNQlil3eF31Bk5n/4cB5lL82zOMpMA4OJyhxCCdUPTo6aMnJ9nqUMqvmqTWJLkiiuK7sqiEpAnYt8CeazdER3VKsARXaC86n6h3fATQ1cucQiJvdhG0PaIInDA/1mAF9HjSiGuRVaRIKd88W2RE2mSWa9m4Q1LHPH1OFGwATJkZHlx3XOVvYyNJ+05/rj1a1zbStIQ+YePVbDubwNuH3/5e+T7++Dn+FrvaMZhxHXRQIRjPNW1JugWEVMjw7nGmIahZGzH6RI4NfvfArCdb7rX1XkYB2CE0LAADiARINMNra/KwDaEqH2ShbZx5KdCLxSBxdteAlO283HYx5gcCW6It0efM96fIi93QdNTJEuq2p18L8SdfcbqLawLVPunryvKjcBqjjUgm7mwb+fiG9qmSJchZQegysKQJ1+ruLqPC//N2V5Fw6qiupMRi4xuCOKeWo+it4C9LBlNw+IDUp2NXOyrP7LBIt+9ATxnRI0lQq7+BkXa5ZRBTHqg58zVj4W6D6zI5oTTsZCSfymwFbI8u+KpGgftP1+Fn07tU6vzZYU7RZokVmNaMwcrzdpT2S2lWh+V3GKgAK+l7vKy37ueo2LYbwULEM8y/etSp254pNvm7CphIDFoavkNdNuAVtZsU/PoiN 6hyeq3hi h6XWMzKs+0ySejdQ08r38g7Qge8sYEbW/CEGqLqNhpYCygMkr15Yfe8AOtmV1fEV5gmXyu5UpzVqHUlo= 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: List-Subscribe: List-Unsubscribe: On Tue, Apr 02, 2024 at 03:15:01PM -0500, Maxwell Bland wrote: > Makes red black tree allocation more flexible on a per-architecture > basis by introducing an optional hooks to refine the red-black tree > structuring and exposing vmalloc functions for clipping vmap areas, > finding vmap areas, and inserting vmap areas. > > With this patch, the red-black vmap tree can be refined to account for > architecture-specific memory management operations, most notably address > space layout randomization, as these features conflict with generic > management of a single vmalloc_start to vmalloc_end range as given by > mm/vmalloc.c. > > For example, x86 is forced to restrict aslr to 1024 possible locations, > which is a very, very small number, and arm64 breaks standard code/data > partitioning altogether, which prevents the enforcement of performant > immmutability on kernel page tables. > > Signed-off-by: Maxwell Bland > --- > include/linux/vmalloc.h | 24 ++++++++++++++++++++++++ > mm/vmalloc.c | 16 ++++++++++------ > 2 files changed, 34 insertions(+), 6 deletions(-) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index 98ea90e90439..3c5ce7ee0bea 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -12,6 +12,7 @@ > > #include > > +struct kmem_cache; > struct vm_area_struct; /* vma defining user mapping in mm_types.h */ > struct notifier_block; /* in notifier.h */ > struct iov_iter; /* in uio.h */ > @@ -125,6 +126,21 @@ static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot) > } > #endif > > +#ifndef arch_skip_va > +static inline bool arch_skip_va(struct vmap_area *va, unsigned long vstart) > +{ > + return false; > +} > +#endif > + > +#ifndef arch_refine_vmap_space > +static inline void arch_refine_vmap_space(struct rb_root *root, > + struct list_head *head, > + struct kmem_cache *cachep) > +{ > +} > +#endif > + > /* > * Highlevel APIs for driver use > */ > @@ -214,6 +230,14 @@ extern struct vm_struct *__get_vm_area_caller(unsigned long size, > void free_vm_area(struct vm_struct *area); > extern struct vm_struct *remove_vm_area(const void *addr); > extern struct vm_struct *find_vm_area(const void *addr); > +extern void insert_vmap_area_augment(struct vmap_area *va, struct rb_node *from, > + struct rb_root *root, > + struct list_head *head); > +extern int va_clip(struct rb_root *root, struct list_head *head, > + struct vmap_area *va, unsigned long nva_start_addr, > + unsigned long size); > +extern struct vmap_area *__find_vmap_area(unsigned long addr, > + struct rb_root *root); > To me it looks like you want to make internal functions as public for everyone which is not good, imho. > struct vmap_area *find_vmap_area(unsigned long addr); > > static inline bool is_vm_area_hugepages(const void *addr) > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 68fa001648cc..de4577a3708e 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -989,7 +989,7 @@ unsigned long vmalloc_nr_pages(void) > return atomic_long_read(&nr_vmalloc_pages); > } > > -static struct vmap_area *__find_vmap_area(unsigned long addr, struct rb_root *root) > +struct vmap_area *__find_vmap_area(unsigned long addr, struct rb_root *root) > { > struct rb_node *n = root->rb_node; > > @@ -1322,7 +1322,7 @@ insert_vmap_area(struct vmap_area *va, > link_va(va, root, parent, link, head); > } > > -static void > +void > insert_vmap_area_augment(struct vmap_area *va, > struct rb_node *from, struct rb_root *root, > struct list_head *head) > @@ -1501,7 +1501,7 @@ find_vmap_lowest_match(struct rb_root *root, unsigned long size, > vstart < va->va_start) { > node = node->rb_left; > } else { > - if (is_within_this_va(va, size, align, vstart)) > + if (!arch_skip_va(va, vstart) && is_within_this_va(va, size, align, vstart)) > return va; > > /* > @@ -1522,7 +1522,8 @@ find_vmap_lowest_match(struct rb_root *root, unsigned long size, > */ > while ((node = rb_parent(node))) { > va = rb_entry(node, struct vmap_area, rb_node); > - if (is_within_this_va(va, size, align, vstart)) > + if (!arch_skip_va(va, vstart) && > + is_within_this_va(va, size, align, vstart)) > return va; > > if (get_subtree_max_size(node->rb_right) >= length && > @@ -1554,7 +1555,7 @@ find_vmap_lowest_linear_match(struct list_head *head, unsigned long size, > struct vmap_area *va; > > list_for_each_entry(va, head, list) { > - if (!is_within_this_va(va, size, align, vstart)) > + if (arch_skip_va(va, vstart) || !is_within_this_va(va, size, align, vstart)) > continue; > arch_skip_va() injections into the search algorithm sounds like a hack and might lead(if i do not miss something, need to check closer) to alloc failures when we go toward a reserved VA but we are not allowed to allocate from. > return va; > @@ -1617,7 +1618,7 @@ classify_va_fit_type(struct vmap_area *va, > return type; > } > > -static __always_inline int > +__always_inline int > va_clip(struct rb_root *root, struct list_head *head, > struct vmap_area *va, unsigned long nva_start_addr, > unsigned long size) > @@ -5129,4 +5130,7 @@ void __init vmalloc_init(void) > vmap_node_shrinker->count_objects = vmap_node_shrink_count; > vmap_node_shrinker->scan_objects = vmap_node_shrink_scan; > shrinker_register(vmap_node_shrinker); > + > + arch_refine_vmap_space(&free_vmap_area_root, &free_vmap_area_list, > + vmap_area_cachep); > } > Why do not you allocate just using a specific range from MODULES_ASLR_START till VMALLOC_END? Thanks! -- Uladzislau Rezki