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 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).