From: Rusty Russell <rusty@rustcorp.com.au>
To: Jessica Yu <jeyu@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Freeing alternatives sections after module init?
Date: Wed, 29 Jun 2016 06:03:20 +0930 [thread overview]
Message-ID: <87d1n1caun.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20160627210727.GA27476@packer-debian-8-amd64.digitalocean.com>
Jessica Yu <jeyu@redhat.com> writes:
> Hi Rusty,
Hi Jessica,
> I noticed that the module loader keeps .altinstructions and
> .altinstr_replacement (which are normally freed after kernel init) in
> core memory after module init, so these sections are never freed for
> modules.
>
> In fact, the module loader seems to keep a number of sections normally
> marked between __init_begin and __init_end (which are then freed in
> free_initmem()) in module core memory, for example on x86, there's
> also .parainstructions and .altinstr_aux.
>
> I was just wondering if this discrepancy was intentional :-)
> Shouldn't these sections be freed after init? Though it probably
> doesn't hurt to keep some of these sections in memory,
> .altinstr_replacement is (for whatever reason) an executable section,
> and is technically not needed anymore after apply_alternatives()
> copies the replacement instructions, so it might be good to free it.
No intention on my part! Definitely nice to fix; I look forward to your
patch.
And sorry for the delay on review of ro_after_init; I'll look at it
today I promise!
Cheers,
Rusty.
prev parent reply other threads:[~2016-06-28 21:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 21:07 Freeing alternatives sections after module init? Jessica Yu
2016-06-28 20:33 ` Rusty Russell [this message]
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=87d1n1caun.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=jeyu@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/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.