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 A4458C3DA4A for ; Tue, 20 Aug 2024 07:13:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C52E6B0083; Tue, 20 Aug 2024 03:13:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 275FB6B0085; Tue, 20 Aug 2024 03:13:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 164096B0088; Tue, 20 Aug 2024 03:13:34 -0400 (EDT) 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 ED7176B0083 for ; Tue, 20 Aug 2024 03:13:33 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 96C3F1A188C for ; Tue, 20 Aug 2024 07:13:33 +0000 (UTC) X-FDA: 82471758306.01.ED735F4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id D7D514000D for ; Tue, 20 Aug 2024 07:13:31 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Gz+4Mc8a; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@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=1724137907; 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=IoyzCH/TEYQH8J7HHjKgP8cmsqVMSXRew+w28LNdyQk=; b=BI5yxZqj3t8+rxZM6tIK24/Wl76ygKacarPSQ1/xepr5OdcYKtv/pKft418fUsfk6Tt6JQ gVk+nynlUwZKHD+jY/d337HcGrhYZzssfkHgeSngoPukGXNytjOYcnkobAoaIodtguGvto BlG5QnQME1t58EfCgkDwes+JoVTAYnI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Gz+4Mc8a; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724137907; a=rsa-sha256; cv=none; b=Af6is9PXWxtKhRG83BSjzckqR5BR0IiW5iLX7PnDekWxQ2dey3WNbbqoq45SBYBf5f90xj nSVKXp6zxVEc3eUOH2Z5BJPcfaA9bu1/NZtTrBLpIzZqCvay+kKgTQAUe/1VwY1TI50o9t CkyfkUzv/YE6dcZ56WH2LfIsjhkF0Os= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C7CBC60A0C; Tue, 20 Aug 2024 07:13:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DD46C4AF09; Tue, 20 Aug 2024 07:13:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724138010; bh=P4Xoto1kb9GxBJ4mRYqIpsziqZnk0OuzLbdWEFfVZxw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gz+4Mc8a6bR73MyttJH1WKF45lDJDtOwWsfsUBDrK6xUysURbUJcwEvyW17ferVr5 b8xWmLKE7Hw4lwwchPrCzinppb3/s7DNzQ56UV9asRxSibNosq/tQewjQ3NGlt8BHu E6TvIE+cC6ndzeFv7iv4yn4hz/XWioUueUZubt9uGQyeRDQbWlHPl3xI778KnsjJVL oNalnsafluqag/HrQfU/xgw9mSUC1vUKX0nZFB5Ej0ZbSGOOkLPNT02Hw9OSAe/CRR 3Jb8vTiQ1oDNQjqzfk4bqcsSrAHxtXvU2dsPRiqgjmvF7bsdLFIanOAfCPEx5gavMS asTEvBA/nwoLg== Date: Tue, 20 Aug 2024 10:13:07 +0300 From: Mike Rapoport To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, corbet@lwn.net, arnd@arndb.de, mcgrof@kernel.org, paulmck@kernel.org, thuth@redhat.com, tglx@linutronix.de, bp@alien8.de, xiongwei.song@windriver.com, ardb@kernel.org, david@redhat.com, vbabka@suse.cz, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, dennis@kernel.org, jhubbard@nvidia.com, yuzhao@google.com, vvvvvv@google.com, rostedt@goodmis.org, iamjoonsoo.kim@lge.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 1/5] alloc_tag: load module tags into separate continuous memory Message-ID: References: <20240819151512.2363698-1-surenb@google.com> <20240819151512.2363698-2-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240819151512.2363698-2-surenb@google.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D7D514000D X-Stat-Signature: kk3k9i47ukr3k6ncpizeuxwpzdzzz857 X-Rspam-User: X-HE-Tag: 1724138011-721627 X-HE-Meta: U2FsdGVkX1/vWjwjDuPvGeACupU1AvVsfvs+tmPplF2xSwYqWDWc8ky/FInqSf/8Un36kmqWnBGh+ll/DNyw77IIM1n8bbRL0B5RbPSmJ9dvptyz4LM5oo8ZAo5C9LrDVNCluesnAJ8gC2gR+rgAOguGBMLfMBw7i3dJ23bK48FEYTLgY4+Z4DRvdGxUkJFqHzF8irw42libALLzN9lMSGJszO5d3sXPyxzadBMe/sOFk+UK3SUzsma2URFSkP+3IKkoCLXRrti0aM1EWih8FKbclzT+sQZDO2ZS3gHXEsIwkZXINeJw/Kk/p3/hP2I4i0Se/AwzYtG9pfjr2ktqODOVd5XzTqrgxL6R5rFpMKPJ5xIew/jkjItZHZaWfQJ/2Im0ZHaabX3g/zlM2n/AZFRbnQv+/cU74FWVEajPuWce8HmA7eHxqwxcelqfNO6E36ZGPzTN1P2HC2HuPNBA0Q7ACSzvGI7Tr4iEj2FwIoHkEz+DvcPr9fRwwrKyxSEGfujfUYakbsFmPs4IpxQSOh5hYHezrMX8HB0Rfop9SFkvEJ8UCAKSomXIBFzrtPnHpxzj2HyRKiXhRN718dEii69BmXZgFWrPkisP/K52MVQ3c8Ca5D44rR6JjMz0uShtpGszM4Sb568iUZhBqf59KU8syuM+J//82EJle4ofwDZ3YbNcX/ktYBs3tjOMeMwtt+b/pd0LWHGx33hZQYzN8+s5OrHxoCNcYh64604mA+FotPoDHivHbfRSO4td+eqodvCWs3lvycdgxicuNp6wewW0lSxowS/n7sES2Y6CZBnHxyThRu7Gia6HbNhpECfmND5NZhW26vwZTQWV2axkDIneIw4E6OTzfaNsMCHGZhnYDQu5LXni40Kmtih55VU/vZdwHG+B0ih29wZtuw84sWqFzYZTke3TzvRC07Ee+9nzaaRdK4GZ801wYFFHwqCFzPIxRvJxaBFVEhN7OTs ygzgYY/b oVPxiF2QG0YNGmnMQHIPx/vt2TuqvIyY9Sfj+StKDvaIGK9aKxGXAclAAsI3HOvjZ4E/OKIJpEkctmkYdP/WNpoBbVjVlXPTGp2HSslycblcx/JvgorTJ6+ntSdVXuw538D2AGsGWr5e4UU6lVXkENruJAUhLQF2iTrHwYUfGgWvEoIS+MiWjJgsKq+fZJOtAQP64Yiz9awd8jzW+Q/ls5/XR3doC58dKrpOQLVj8HfkQbRi62BAjAbF0Uf2I14knWQzKU7Rol+ECN0KvFHqioYpJBcHMc8R8Hf9FQfo+m5meTwZyXPaZwGTThcZIHr02pmr92rEeOq5QqmQ= 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 Mon, Aug 19, 2024 at 08:15:07AM -0700, Suren Baghdasaryan wrote: > When a module gets unloaded there is a possibility that some of the > allocations it made are still used and therefore the allocation tags > corresponding to these allocations are still referenced. As such, the > memory for these tags can't be freed. This is currently handled as an > abnormal situation and module's data section is not being unloaded. > To handle this situation without keeping module's data in memory, > allow codetags with longer lifespan than the module to be loaded into > their own separate memory. The in-use memory areas and gaps after > module unloading in this separate memory are tracked using maple trees. > Allocation tags arrange their separate memory so that it is virtually > contiguous and that will allow simple allocation tag indexing later on > in this patchset. The size of this virtually contiguous memory is set > to store up to 100000 allocation tags and max_module_alloc_tags kernel > parameter is introduced to change this size. > > Signed-off-by: Suren Baghdasaryan > --- > .../admin-guide/kernel-parameters.txt | 4 + > include/asm-generic/codetag.lds.h | 19 ++ > include/linux/alloc_tag.h | 13 +- > include/linux/codetag.h | 35 ++- > kernel/module/main.c | 67 +++-- > lib/alloc_tag.c | 245 ++++++++++++++++-- > lib/codetag.c | 101 +++++++- > scripts/module.lds.S | 5 +- > 8 files changed, 429 insertions(+), 60 deletions(-) ... > diff --git a/include/linux/codetag.h b/include/linux/codetag.h > index c2a579ccd455..c4a3dd60205e 100644 > --- a/include/linux/codetag.h > +++ b/include/linux/codetag.h > @@ -35,8 +35,13 @@ struct codetag_type_desc { > size_t tag_size; > void (*module_load)(struct codetag_type *cttype, > struct codetag_module *cmod); > - bool (*module_unload)(struct codetag_type *cttype, > + void (*module_unload)(struct codetag_type *cttype, > struct codetag_module *cmod); > + void (*module_replaced)(struct module *mod, struct module *new_mod); > + bool (*needs_section_mem)(struct module *mod, unsigned long size); > + void *(*alloc_section_mem)(struct module *mod, unsigned long size, > + unsigned int prepend, unsigned long align); > + void (*free_section_mem)(struct module *mod, bool unused); > }; > > struct codetag_iterator { > @@ -71,11 +76,31 @@ struct codetag_type * > codetag_register_type(const struct codetag_type_desc *desc); > > #if defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) > + > +bool codetag_needs_module_section(struct module *mod, const char *name, > + unsigned long size); > +void *codetag_alloc_module_section(struct module *mod, const char *name, > + unsigned long size, unsigned int prepend, > + unsigned long align); > +void codetag_free_module_sections(struct module *mod); > +void codetag_module_replaced(struct module *mod, struct module *new_mod); > void codetag_load_module(struct module *mod); > -bool codetag_unload_module(struct module *mod); > -#else > +void codetag_unload_module(struct module *mod); > + > +#else /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ > + > +static inline bool > +codetag_needs_module_section(struct module *mod, const char *name, > + unsigned long size) { return false; } > +static inline void * > +codetag_alloc_module_section(struct module *mod, const char *name, > + unsigned long size, unsigned int prepend, > + unsigned long align) { return NULL; } > +static inline void codetag_free_module_sections(struct module *mod) {} > +static inline void codetag_module_replaced(struct module *mod, struct module *new_mod) {} > static inline void codetag_load_module(struct module *mod) {} > -static inline bool codetag_unload_module(struct module *mod) { return true; } > -#endif > +static inline void codetag_unload_module(struct module *mod) {} > + > +#endif /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ Maybe I'm missing something, but can't alloc_tag::module_unload() just copy the tags that cannot be freed somewhere outside of module sections and then free the module? The heavy lifting would be localized to alloc_tags rather than spread all over. -- Sincerely yours, Mike.