From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752279AbcF0VIS (ORCPT ); Mon, 27 Jun 2016 17:08:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35798 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751948AbcF0VIQ (ORCPT ); Mon, 27 Jun 2016 17:08:16 -0400 Date: Mon, 27 Jun 2016 17:07:27 -0400 From: Jessica Yu To: Rusty Russell Cc: linux-kernel@vger.kernel.org Subject: Freeing alternatives sections after module init? Message-ID: <20160627210727.GA27476@packer-debian-8-amd64.digitalocean.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 27 Jun 2016 21:07:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rusty, 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. Thanks, Jessica