From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: mcgrof@kernel.org, linux-modules@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
Song Liu <song@kernel.org>
Subject: Re: [PATCH] module: Refine kmemleak scanned areas
Date: Mon, 9 Sep 2024 09:52:57 +0100 [thread overview]
Message-ID: <Zt63aV2zmkOkwRc3@arm.com> (raw)
In-Reply-To: <Zt6mcvkzPI8WNgHl@google.com>
On Mon, Sep 09, 2024 at 08:40:34AM +0100, Vincent Donnefort wrote:
> On Sat, Sep 07, 2024 at 03:12:13PM +0100, Catalin Marinas wrote:
> > On Fri, Sep 06, 2024 at 04:38:56PM +0100, Vincent Donnefort wrote:
> > > commit ac3b43283923 ("module: replace module_layout with module_memory")
> > > introduced a set of memory regions for the module layout sharing the
> > > same attributes but didn't update the kmemleak scanned areas which
> > > intended to limit kmemleak scan to sections containing writable data.
> > > This means sections such as .text and .rodata are scanned by kmemleak.
> > >
> > > Refine the scanned areas for modules by limiting it to MOD_TEXT and
> > > MOD_INIT_TEXT mod_mem regions.
> > >
> > > CC: Song Liu <song@kernel.org>
> > > CC: Catalin Marinas <catalin.marinas@arm.com>
> > > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> > >
> > > diff --git a/kernel/module/debug_kmemleak.c b/kernel/module/debug_kmemleak.c
> > > index 12a569d361e8..b4cc03842d70 100644
> > > --- a/kernel/module/debug_kmemleak.c
> > > +++ b/kernel/module/debug_kmemleak.c
> > > @@ -12,19 +12,9 @@
> > > void kmemleak_load_module(const struct module *mod,
> > > const struct load_info *info)
> > > {
> > > - unsigned int i;
> > > -
> > > - /* only scan the sections containing data */
> > > - kmemleak_scan_area(mod, sizeof(struct module), GFP_KERNEL);
> > > -
> > > - for (i = 1; i < info->hdr->e_shnum; i++) {
> > > - /* Scan all writable sections that's not executable */
> > > - if (!(info->sechdrs[i].sh_flags & SHF_ALLOC) ||
> > > - !(info->sechdrs[i].sh_flags & SHF_WRITE) ||
> > > - (info->sechdrs[i].sh_flags & SHF_EXECINSTR))
> > > - continue;
> > > -
> > > - kmemleak_scan_area((void *)info->sechdrs[i].sh_addr,
> > > - info->sechdrs[i].sh_size, GFP_KERNEL);
> > > + /* only scan writable, non-executable sections */
> > > + for_each_mod_mem_type(type) {
> > > + if (type != MOD_DATA && type != MOD_INIT_DATA)
> > > + kmemleak_no_scan(mod->mem[type].base);
> > > }
> > > }
> >
> > I lost track of how module memory allocation works. Is struct module
> > still scanned after this change?
>
> That section being RW, it will be part of the MOD_DATA vmalloc and scanned.
Ah, makes sense. I'm fine with this patch, it simplifies the code now
that we have mod->mem[type]. I wouldn't say it's a fix, though no
backporting needed.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
next prev parent reply other threads:[~2024-09-09 8:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-06 15:38 [PATCH] module: Refine kmemleak scanned areas Vincent Donnefort
2024-09-06 23:26 ` Luis Chamberlain
2024-09-07 14:12 ` Catalin Marinas
2024-09-09 7:40 ` Vincent Donnefort
2024-09-09 8:52 ` Catalin Marinas [this message]
2024-09-09 10:23 ` Vincent Donnefort
2024-09-09 21:25 ` Luis Chamberlain
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=Zt63aV2zmkOkwRc3@arm.com \
--to=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=song@kernel.org \
--cc=vdonnefort@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.