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
