public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>
Subject: Re: linux-next: manual merge of the modules tree with the mm tree
Date: Fri, 17 May 2024 09:23:47 +1000	[thread overview]
Message-ID: <20240517092347.469578bb@canb.auug.org.au> (raw)
In-Reply-To: <20240412120421.27d86c34@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]

Hi all,

On Fri, 12 Apr 2024 12:04:21 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the modules tree got a conflict in:
> 
>   kernel/module/main.c
> 
> between commit:
> 
>   58782d7a7ccd ("lib: prevent module unloading if memory is not freed")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   a4ee8c9b86bd ("module: make module_memory_{alloc,free} more self-contained")
> 
> from the modules tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc kernel/module/main.c
> index 2d25eebc549d,d56b7df0cbb6..000000000000
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@@ -56,8 -56,8 +56,9 @@@
>   #include <linux/dynamic_debug.h>
>   #include <linux/audit.h>
>   #include <linux/cfi.h>
>  +#include <linux/codetag.h>
>   #include <linux/debugfs.h>
> + #include <linux/execmem.h>
>   #include <uapi/linux/module.h>
>   #include "internal.h"
>   
> @@@ -1204,26 -1194,51 +1195,55 @@@ static bool mod_mem_use_vmalloc(enum mo
>   		mod_mem_type_is_core_data(type);
>   }
>   
> - static void *module_memory_alloc(unsigned int size, enum mod_mem_type type)
> + static int module_memory_alloc(struct module *mod, enum mod_mem_type type)
>   {
> + 	unsigned int size = PAGE_ALIGN(mod->mem[type].size);
> + 	void *ptr;
> + 
> + 	mod->mem[type].size = size;
> + 
>   	if (mod_mem_use_vmalloc(type))
> - 		return vzalloc(size);
> - 	return module_alloc(size);
> + 		ptr = vmalloc(size);
> + 	else
> + 		ptr = execmem_alloc(EXECMEM_MODULE_TEXT, size);
> + 
> + 	if (!ptr)
> + 		return -ENOMEM;
> + 
> + 	/*
> + 	 * The pointer to these blocks of memory are stored on the module
> + 	 * structure and we keep that around so long as the module is
> + 	 * around. We only free that memory when we unload the module.
> + 	 * Just mark them as not being a leak then. The .init* ELF
> + 	 * sections *do* get freed after boot so we *could* treat them
> + 	 * slightly differently with kmemleak_ignore() and only grey
> + 	 * them out as they work as typical memory allocations which
> + 	 * *do* eventually get freed, but let's just keep things simple
> + 	 * and avoid *any* false positives.
> + 	 */
> + 	kmemleak_not_leak(ptr);
> + 
> + 	memset(ptr, 0, size);
> + 	mod->mem[type].base = ptr;
> + 
> + 	return 0;
>   }
>   
> - static void module_memory_free(void *ptr, enum mod_mem_type type,
>  -static void module_memory_free(struct module *mod, enum mod_mem_type type)
> ++static void module_memory_free(struct module *mod, enum mod_mem_type type,
>  +			       bool unload_codetags)
>   {
> + 	void *ptr = mod->mem[type].base;
> + 
>  +	if (!unload_codetags && mod_mem_type_is_core_data(type))
>  +		return;
>  +
>   	if (mod_mem_use_vmalloc(type))
>   		vfree(ptr);
>   	else
> - 		module_memfree(ptr);
> + 		execmem_free(ptr);
>   }
>   
>  -static void free_mod_mem(struct module *mod)
>  +static void free_mod_mem(struct module *mod, bool unload_codetags)
>   {
>   	for_each_mod_mem_type(type) {
>   		struct module_memory *mod_mem = &mod->mem[type];
> @@@ -1234,13 -1249,12 +1254,13 @@@
>   		/* Free lock-classes; relies on the preceding sync_rcu(). */
>   		lockdep_free_key_range(mod_mem->base, mod_mem->size);
>   		if (mod_mem->size)
> - 			module_memory_free(mod_mem->base, type,
>  -			module_memory_free(mod, type);
> ++			module_memory_free(mod, type,
>  +					   unload_codetags);
>   	}
>   
>   	/* MOD_DATA hosts mod, so free it at last */
>   	lockdep_free_key_range(mod->mem[MOD_DATA].base, mod->mem[MOD_DATA].size);
> - 	module_memory_free(mod->mem[MOD_DATA].base, MOD_DATA, unload_codetags);
>  -	module_memory_free(mod, MOD_DATA);
> ++	module_memory_free(mod, MOD_DATA, unload_codetags);
>   }
>   
>   /* Free a module, remove from lists, etc. */
> @@@ -2309,7 -2301,7 +2314,7 @@@ static int move_module(struct module *m
>   	return 0;
>   out_enomem:
>   	for (t--; t >= 0; t--)
> - 		module_memory_free(mod->mem[t].base, t, true);
>  -		module_memory_free(mod, t);
> ++		module_memory_free(mod, t, true);
>   	return ret;
>   }
>   

This is now a conflict between the mm-stable tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2024-05-16 23:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12  2:04 linux-next: manual merge of the modules tree with the mm tree Stephen Rothwell
2024-05-16 23:23 ` Stephen Rothwell [this message]
2024-05-16 23:35   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-04-24  2:20 Stephen Rothwell
2024-05-16 23:26 ` Stephen Rothwell
2024-04-24  2:39 Stephen Rothwell
2024-04-24 20:07 ` Andrew Morton
2024-04-24 20:17   ` Suren Baghdasaryan
2024-04-24 20:29   ` Mike Rapoport
2024-04-24 20:33     ` Suren Baghdasaryan
2024-04-24 21:24       ` Suren Baghdasaryan
2024-04-25  1:37         ` Stephen Rothwell

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=20240517092347.469578bb@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=rppt@kernel.org \
    --cc=surenb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox