linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Casey Chen <cachen@purestorage.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: 00107082@163.com, akpm@linux-foundation.org, cl@gentwo.org,
	 dennis@kernel.org, kent.overstreet@linux.dev,
	linux-kernel@vger.kernel.org,  linux-mm@kvack.org,
	pasha.tatashin@soleen.com, tj@kernel.org,
	 yzhong@purestorage.com
Subject: Re: comments on patch "alloc_tag: allocate percpu counters for module tags dynamically"
Date: Tue, 20 May 2025 16:48:23 -0700	[thread overview]
Message-ID: <CALCePG1uoNN4vB3HguOi+ZYjwUcTPHmtp4RCZey0r6qCUJMLCg@mail.gmail.com> (raw)
In-Reply-To: <CAJuCfpEz2mbVmGJnp0JHKsip2HVkp+=yHOj3oRtDrKzXXG5Xag@mail.gmail.com>

On Tue, May 20, 2025 at 4:26 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Tue, May 20, 2025 at 4:16 PM Casey Chen <cachen@purestorage.com> wrote:
> >
> > Hi Suren,
>
> Hi Casey,
>
> >
> > I have two questions on this patch.
> > 1. If load_module() fails to allocate memory for percpu counters, should we call codetag_free_module_sections() to clean up module tags memory ?
>
> Does this address your question:
> https://lore.kernel.org/all/20250518101212.19930-1-00107082@163.com/
>

module_deallocate() is called in error handling of load_module(). And
codetag_load_module() is at the very end of load_module(). If counter
allocation fails, it doesn't go to the error path to clean up module
tag memory.

My code base is at a5806cd506af ("Linux 6.15-rc7")
3250 /*
3251  * Allocate and load the module: note that size of section 0 is always
3252  * zero, and we rely on this for optional sections.
3253  */
3254 static int load_module(struct load_info *info, const char __user *uargs,
3255                        int flags)
3256 {
...
3403
3404         codetag_load_module(mod);
3405
3406         /* Done! */
3407         trace_module_load(mod);
3408
3409         return do_init_module(mod);
...
3445  free_module:
3446         mod_stat_bump_invalid(info, flags);
3447         /* Free lock-classes; relies on the preceding sync_rcu() */
3448         for_class_mod_mem_type(type, core_data) {
3449                 lockdep_free_key_range(mod->mem[type].base,
3450                                        mod->mem[type].size);
3451         }
3452
3453         module_memory_restore_rox(mod);
3454         module_deallocate(mod, info);


> > 2. How about moving percpu counters allocation to move_module() where codetag_alloc_module_section() is called ? So they can be cleaned up together.
>
> That would not work because tag->counters are initialized with NULL
> after move_module() executes, so if we allocate there our allocations
> will be overridden. We have to do that at the end of load_module()
> where codetag_load_module() is.

codetag_alloc_module_section() is called in move_module() to allocate
module tag memory. I mean we can also allocate memory for percpu
counters inside move_module().
We have implemented such a thing in our code base and it works fine.
Just do it right after copying ELF sections to memory. If it fails it
goes to the error path and calls codetag_free_module_sections() to
clean up.

2650                 if (codetag_needs_module_section(mod, sname,
shdr->sh_size)) {
2651                         dest = codetag_alloc_module_section(mod,
sname, shdr->sh_size,
2652
arch_mod_section_prepend(mod, i), shdr->sh_addralign);

> Thanks,
> Suren.
>
> >
> > Thanks,
> > Casey


  reply	other threads:[~2025-05-20 23:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-17  0:07 [PATCH 1/1] alloc_tag: allocate percpu counters for module tags dynamically Suren Baghdasaryan
2025-05-17  6:09 ` David Wang
2025-05-19 22:51 ` [PATCH " Andrew Morton
2025-05-19 23:13   ` Suren Baghdasaryan
2025-05-20  0:21     ` Andrew Morton
2025-05-20  3:19       ` Suren Baghdasaryan
2025-05-20 23:16 ` comments on patch "alloc_tag: allocate percpu counters for module tags dynamically" Casey Chen
2025-05-20 23:26   ` Suren Baghdasaryan
2025-05-20 23:48     ` Casey Chen [this message]
2025-05-21  0:45       ` Suren Baghdasaryan
2025-05-21  1:22         ` Suren Baghdasaryan
2025-05-21 16:16           ` 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=CALCePG1uoNN4vB3HguOi+ZYjwUcTPHmtp4RCZey0r6qCUJMLCg@mail.gmail.com \
    --to=cachen@purestorage.com \
    --cc=00107082@163.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=dennis@kernel.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=yzhong@purestorage.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