Re: mod->klp set on copy ok ?

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Fri, Mar 17, 2023 at 12:00:40PM -0700, Luis Chamberlain wrote:
> > I dug into that code years ago, and the above sounds right.
> > 
> > The .ko file has a .gnu.linkonce.this_module section whose data is just
> > the original "struct module __this_module" which is created by the
> > module build (from foo.mod.c).
> > 
> > At the beginning of the finit_module() syscall, the .ko file's ELF
> > sections get copied (and optionally decompressed) into kernel memory.
> > Then 'mod' just points to the copied __this_module struct.
> > 
> > Then mod->klp (and possibly mod->taint) get set.
> > 
> > Then in layout_and_allocate(), that 'mod' gets memcpy'd into the second
> > (and final) in-kernel copy of 'struct module':
> > 
> >  		if (shdr->sh_type != SHT_NOBITS)
> >  			memcpy(dest, (void *)shdr->sh_addr, shdr->sh_size);
> >  		/* Update sh_addr to point to copy in image. */
> >  		shdr->sh_addr = (unsigned long)dest;
> > 
> > I suspect you don't see the size changing when you add to 'struct
> > module' because it's ____cacheline_aligned.
> > 
> > It's all rather obtuse, but working as designed as far as I can tell.
> 
> Ah, well it is beyond a ____cacheline_aligned issue! It would seem our build
> system does not incur a full re-build of $foo.mod.c if the size of struct module
> changes. Doing a full rebuild does get the right drift size change in
> struct module:

Ah, ok.  It sounds like build dependencies are broken for *.mod.c.

The added validations in the patch look reasonable, though the broken
build dependencies should also get fixed.

-- 
Josh