From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752660AbcF1V3i (ORCPT <rfc822;w@1wt.eu>);
	Tue, 28 Jun 2016 17:29:38 -0400
Received: from ozlabs.org ([103.22.144.67]:37088 "EHLO ozlabs.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752589AbcF1V3g (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 28 Jun 2016 17:29:36 -0400
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?
In-Reply-To: <20160627210727.GA27476@packer-debian-8-amd64.digitalocean.com>
References: <20160627210727.GA27476@packer-debian-8-amd64.digitalocean.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 29 Jun 2016 06:03:20 +0930
Message-ID: <87d1n1caun.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.