From: Mike Rapoport <rppt@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
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
Date: Tue, 20 Aug 2024 10:13:07 +0300 [thread overview]
Message-ID: <ZsRCAy5cCp0Ig3I/@kernel.org> (raw)
In-Reply-To: <20240819151512.2363698-2-surenb@google.com>
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 <surenb@google.com>
> ---
> .../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.
next prev parent reply other threads:[~2024-08-20 7:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 15:15 [PATCH 0/5] page allocation tag compression Suren Baghdasaryan
2024-08-19 15:15 ` [PATCH 1/5] alloc_tag: load module tags into separate continuous memory Suren Baghdasaryan
2024-08-20 7:13 ` Mike Rapoport [this message]
2024-08-20 7:26 ` Suren Baghdasaryan
2024-08-20 11:10 ` Kent Overstreet
2024-08-20 15:31 ` Liam R. Howlett
2024-08-20 18:35 ` Suren Baghdasaryan
2024-08-19 15:15 ` [PATCH 2/5] alloc_tag: eliminate alloc_tag_ref_set Suren Baghdasaryan
2024-08-19 15:15 ` [PATCH 3/5] alloc_tag: introduce pgalloc_tag_ref to abstract page tag references Suren Baghdasaryan
2024-08-19 15:15 ` [PATCH 4/5] alloc_tag: make page allocation tag reference size configurable Suren Baghdasaryan
2024-08-19 15:15 ` [PATCH 5/5] alloc_tag: config to store page allocation tag refs in page flags Suren Baghdasaryan
2024-08-19 19:34 ` Matthew Wilcox
2024-08-19 20:39 ` Suren Baghdasaryan
2024-08-19 20:40 ` Matthew Wilcox
2024-08-20 1:46 ` Andrew Morton
2024-08-20 2:21 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZsRCAy5cCp0Ig3I/@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=dennis@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jhubbard@nvidia.com \
--cc=kaleshsingh@google.com \
--cc=keescook@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=kernel-team@android.com \
--cc=liam.howlett@oracle.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mhocko@suse.com \
--cc=minchan@google.com \
--cc=pasha.tatashin@soleen.com \
--cc=paulmck@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=souravpanda@google.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=thuth@redhat.com \
--cc=vbabka@suse.cz \
--cc=vvvvvv@google.com \
--cc=willy@infradead.org \
--cc=xiongwei.song@windriver.com \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).