| Message ID | 20201125010541.309848-1-willmcvicker@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Adds support to capture module's SCM version | expand |
On Wed, Nov 25, 2020 at 01:05:39AM +0000, Will McVicker wrote: > Hi All, > > I have updated the patchset to: > > *) Include Documentation. > *) Use a consistent output pattern for the SCM version. > > In my debugging, I found that the vermagic reported by modinfo can actually > vary based on how the module was loaded. For example, if you have a module in > the initramfs that is newer than the module on disk, then the initramfs module > will be loaded (not the one on disk) during boot. Then, when you run the > command: > > $ modinfo MODULENAME > > The vermagic returned will actually be the vermagic of the module on disk and > not the one in the initramfs which was actually loaded. With that being said, > adding this scmversion attribute ensures that you can *always* get the correct > SCM version of the module that loaded. > > Please take a look at the updated patch and provide any comments you find. > > Thanks, > Will > > Will McVicker (2): > scripts/setlocalversion: allow running in a subdir > modules: add scmversion field > > Documentation/ABI/stable/sysfs-module | 17 +++++++++++++++++ > include/linux/module.h | 1 + > kernel/module.c | 2 ++ > scripts/Makefile.modpost | 20 ++++++++++++++++++++ > scripts/mod/modpost.c | 24 +++++++++++++++++++++++- > scripts/setlocalversion | 5 ++--- > 6 files changed, 65 insertions(+), 4 deletions(-) > > -- > 2.29.2.454.gaff20da3a2-goog > Hi Jessica, Masahiro, and Michal, Friendly reminder :) Thanks, Will
I think your decription still shows absolutely no benefit for the kernel, so I'not sure why anyone would want to waste time on this.
On Fri, Dec 04, 2020 at 07:51:59AM +0000, Christoph Hellwig wrote: > I think your decription still shows absolutely no benefit for the > kernel, so I'not sure why anyone would want to waste time on this. Hi Christoph, Did you get a chance to read my earlier responses regarding the uses for in-tree modules? The biggest benefit for the upstream community is being about to get the SCM version for *any* module (including in-tree modules) in the initramfs via the sysfs node. Currently there is no way to do that and there is no guarantee that those modules in the initramfs were compiled with the running kernel. In fact, running, modinfo -F vermagic MODULENAME will return an invalid vermagic string if the same module with different vermagic strings exists in the initramfs and on disk because modinfo only looks at the module on disk (not in memory). The second most useful benefit goes hand-in-hand with MODVERSIONS. The purpose of MODVERSIONS is to create a stable interface that allows one to update the kernel and kernel modules (including in-tree modules) independently. So when developers do update their kernels independently (think for security bug fixes), the `scmversion` attribute guarantees developers that they can still identify the modules' or kernel's SCM version. I hope that helps. If not, then please let me know why these reasons "show absolutely no benefit for the kernel?" Thanks, Will
On Fri, Dec 04, 2020 at 10:13:56AM -0800, Will McVicker wrote: > On Fri, Dec 04, 2020 at 07:51:59AM +0000, Christoph Hellwig wrote: > > I think your decription still shows absolutely no benefit for the > > kernel, so I'not sure why anyone would want to waste time on this. > Hi Christoph, > > Did you get a chance to read my earlier responses regarding the uses for > in-tree modules? > > The biggest benefit for the upstream community is being about to get the SCM > version for *any* module (including in-tree modules) in the initramfs via the > sysfs node. Currently there is no way to do that and there is no guarantee that That assumes the SCM version of a module has any kind of meaning for an in-tree module. Which it doesn't. If you care about the SCM version of an in-tree module the only thing we need is one single global sysfs file.
On Fri, Dec 04, 2020 at 06:18:08PM +0000, Christoph Hellwig wrote: > On Fri, Dec 04, 2020 at 10:13:56AM -0800, Will McVicker wrote: > > On Fri, Dec 04, 2020 at 07:51:59AM +0000, Christoph Hellwig wrote: > > > I think your decription still shows absolutely no benefit for the > > > kernel, so I'not sure why anyone would want to waste time on this. > > Hi Christoph, > > > > Did you get a chance to read my earlier responses regarding the uses for > > in-tree modules? > > > > The biggest benefit for the upstream community is being about to get the SCM > > version for *any* module (including in-tree modules) in the initramfs via the > > sysfs node. Currently there is no way to do that and there is no guarantee that > > That assumes the SCM version of a module has any kind of meaning for > an in-tree module. Which it doesn't. If you care about the SCM version > of an in-tree module the only thing we need is one single global sysfs > file. Why doesn't it have meaning? With MODVERSIONS, you are able to update in-tree kernel modules independently of the kernel. That means you can update as many in-tree modules as you want which would create many different SCM versions (1 per every module update). Also you can update the kernel independently of the in-tree modules introducing another SCM version. --Will