[PATCH] module: remove MODULE_VERSION()

[PATCH] module: remove MODULE_VERSION()

[Greg Kroah-Hartman]

Module "versions" do not make sense as the kernel is built all at once,
the "version" is the overall kernel version number, so modules can not
really be described as having a unique version given that they rely on
the infrastructure of the whole kernel.

For now, just make this an "empty" define, to keep existing code
building properly as the tree is slowly purged of the use of this over
time.

This macro will be removed entirely in the future when there are no
in-tree users.

Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Daniel Gomez <da.gomez@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Aaron Tomlin <atomlin@atomlin.com>
Cc: Shyam Saini <shyamsaini@linux.microsoft.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Thorsten Blum <thorsten.blum@linux.dev>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 include/linux/module.h | 56 +++++++++---------------------------------
 kernel/params.c        | 30 ----------------------
 2 files changed, 11 insertions(+), 75 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 14f391b186c6..37cb369b4c3a 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -62,15 +62,6 @@ struct module_attribute {
 	void (*free)(struct module *);
 };
 
-struct module_version_attribute {
-	struct module_attribute mattr;
-	const char *module_name;
-	const char *version;
-};
-
-extern ssize_t __modver_version_show(const struct module_attribute *,
-				     struct module_kobject *, char *);
-
 extern const struct module_attribute module_uevent;
 
 /* These are either module local, or the kernel's dummy ones. */
@@ -256,43 +247,18 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 static typeof(name) __mod_device_table(type, name)			\
   __attribute__ ((used, alias(__stringify(name))))
 
-/* Version of form [<epoch>:]<version>[-<extra-version>].
- * Or for CVS/RCS ID version, everything but the number is stripped.
- * <epoch>: A (small) unsigned integer which allows you to start versions
- * anew. If not mentioned, it's zero.  eg. "2:1.0" is after
- * "1:2.0".
-
- * <version>: The <version> may contain only alphanumerics and the
- * character `.'.  Ordered by numeric sort for numeric parts,
- * ascii sort for ascii parts (as per RPM or DEB algorithm).
-
- * <extraversion>: Like <version>, but inserted for local
- * customizations, eg "rh3" or "rusty1".
-
- * Using this automatically adds a checksum of the .c files and the
- * local headers in "srcversion".
+/*
+ * Module "versions" do not make sense as the kernel is built all at once, the
+ * "version" is the overall kernel version number, so modules can not really be
+ * described as having a unique version given that they rely on the
+ * infrastructure of the whole kernel.
+ *
+ * For now, just make this an "empty" define, to keep existing code building
+ * properly as the tree is slowly purged of the use of this over time.
+ *
+ * It will be removed in the future when there are no in-tree users.
  */
-
-#if defined(MODULE) || !defined(CONFIG_SYSFS)
-#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
-#else
-#define MODULE_VERSION(_version)					\
-	MODULE_INFO(version, _version);					\
-	static const struct module_version_attribute __modver_attr	\
-		__used __section("__modver")				\
-		__aligned(__alignof__(struct module_version_attribute)) \
-		= {							\
-			.mattr	= {					\
-				.attr	= {				\
-					.name	= "version",		\
-					.mode	= S_IRUGO,		\
-				},					\
-				.show	= __modver_version_show,	\
-			},						\
-			.module_name	= KBUILD_MODNAME,		\
-			.version	= _version,			\
-		}
-#endif
+#define MODULE_VERSION(_version)
 
 /* Optional firmware file (or files) needed by the module
  * format is simply firmware file name.  Multiple firmware
diff --git a/kernel/params.c b/kernel/params.c
index 7188a12dbe86..1b14b1ab5fcb 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -846,35 +846,6 @@ static void __init param_sysfs_builtin(void)
 	}
 }
 
-ssize_t __modver_version_show(const struct module_attribute *mattr,
-			      struct module_kobject *mk, char *buf)
-{
-	const struct module_version_attribute *vattr =
-		container_of_const(mattr, struct module_version_attribute, mattr);
-
-	return scnprintf(buf, PAGE_SIZE, "%s\n", vattr->version);
-}
-
-extern const struct module_version_attribute __start___modver[];
-extern const struct module_version_attribute __stop___modver[];
-
-static void __init version_sysfs_builtin(void)
-{
-	const struct module_version_attribute *vattr;
-	struct module_kobject *mk;
-	int err;
-
-	for (vattr = __start___modver; vattr < __stop___modver; vattr++) {
-		mk = lookup_or_create_module_kobject(vattr->module_name);
-		if (mk) {
-			err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
-			WARN_ON_ONCE(err);
-			kobject_uevent(&mk->kobj, KOBJ_ADD);
-			kobject_put(&mk->kobj);
-		}
-	}
-}
-
 /* module-related sysfs stuff */
 
 static ssize_t module_attr_show(struct kobject *kobj,
@@ -977,7 +948,6 @@ static int __init param_sysfs_builtin_init(void)
 	if (!module_kset)
 		return -ENOMEM;
 
-	version_sysfs_builtin();
 	param_sysfs_builtin();
 
 	return 0;
-- 
2.53.0

Re: [PATCH] module: remove MODULE_VERSION()

[Greg Kroah-Hartman]

On Fri, Mar 13, 2026 at 03:20:42PM +0100, Greg Kroah-Hartman wrote:
> Module "versions" do not make sense as the kernel is built all at once,
> the "version" is the overall kernel version number, so modules can not
> really be described as having a unique version given that they rely on
> the infrastructure of the whole kernel.
> 
> For now, just make this an "empty" define, to keep existing code
> building properly as the tree is slowly purged of the use of this over
> time.
> 
> This macro will be removed entirely in the future when there are no
> in-tree users.
> 
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Daniel Gomez <da.gomez@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Aaron Tomlin <atomlin@atomlin.com>
> Cc: Shyam Saini <shyamsaini@linux.microsoft.com>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Thorsten Blum <thorsten.blum@linux.dev>
> Cc: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  include/linux/module.h | 56 +++++++++---------------------------------
>  kernel/params.c        | 30 ----------------------
>  2 files changed, 11 insertions(+), 75 deletions(-)


Sami just pointed out to me off-list that maybe I should also drop the
srcversion stuff too.  I'll gladly do that too, does anyone know if
anyone even uses that anymore?

thanks,

greg k-h


> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 14f391b186c6..37cb369b4c3a 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -62,15 +62,6 @@ struct module_attribute {
>  	void (*free)(struct module *);
>  };
>  
> -struct module_version_attribute {
> -	struct module_attribute mattr;
> -	const char *module_name;
> -	const char *version;
> -};
> -
> -extern ssize_t __modver_version_show(const struct module_attribute *,
> -				     struct module_kobject *, char *);
> -
>  extern const struct module_attribute module_uevent;
>  
>  /* These are either module local, or the kernel's dummy ones. */
> @@ -256,43 +247,18 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
>  static typeof(name) __mod_device_table(type, name)			\
>    __attribute__ ((used, alias(__stringify(name))))
>  
> -/* Version of form [<epoch>:]<version>[-<extra-version>].
> - * Or for CVS/RCS ID version, everything but the number is stripped.
> - * <epoch>: A (small) unsigned integer which allows you to start versions
> - * anew. If not mentioned, it's zero.  eg. "2:1.0" is after
> - * "1:2.0".
> -
> - * <version>: The <version> may contain only alphanumerics and the
> - * character `.'.  Ordered by numeric sort for numeric parts,
> - * ascii sort for ascii parts (as per RPM or DEB algorithm).
> -
> - * <extraversion>: Like <version>, but inserted for local
> - * customizations, eg "rh3" or "rusty1".
> -
> - * Using this automatically adds a checksum of the .c files and the
> - * local headers in "srcversion".
> +/*
> + * Module "versions" do not make sense as the kernel is built all at once, the
> + * "version" is the overall kernel version number, so modules can not really be
> + * described as having a unique version given that they rely on the
> + * infrastructure of the whole kernel.
> + *
> + * For now, just make this an "empty" define, to keep existing code building
> + * properly as the tree is slowly purged of the use of this over time.
> + *
> + * It will be removed in the future when there are no in-tree users.
>   */
> -
> -#if defined(MODULE) || !defined(CONFIG_SYSFS)
> -#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
> -#else
> -#define MODULE_VERSION(_version)					\
> -	MODULE_INFO(version, _version);					\
> -	static const struct module_version_attribute __modver_attr	\
> -		__used __section("__modver")				\
> -		__aligned(__alignof__(struct module_version_attribute)) \
> -		= {							\
> -			.mattr	= {					\
> -				.attr	= {				\
> -					.name	= "version",		\
> -					.mode	= S_IRUGO,		\
> -				},					\
> -				.show	= __modver_version_show,	\
> -			},						\
> -			.module_name	= KBUILD_MODNAME,		\
> -			.version	= _version,			\
> -		}
> -#endif
> +#define MODULE_VERSION(_version)
>  
>  /* Optional firmware file (or files) needed by the module
>   * format is simply firmware file name.  Multiple firmware
> diff --git a/kernel/params.c b/kernel/params.c
> index 7188a12dbe86..1b14b1ab5fcb 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -846,35 +846,6 @@ static void __init param_sysfs_builtin(void)
>  	}
>  }
>  
> -ssize_t __modver_version_show(const struct module_attribute *mattr,
> -			      struct module_kobject *mk, char *buf)
> -{
> -	const struct module_version_attribute *vattr =
> -		container_of_const(mattr, struct module_version_attribute, mattr);
> -
> -	return scnprintf(buf, PAGE_SIZE, "%s\n", vattr->version);
> -}
> -
> -extern const struct module_version_attribute __start___modver[];
> -extern const struct module_version_attribute __stop___modver[];
> -
> -static void __init version_sysfs_builtin(void)
> -{
> -	const struct module_version_attribute *vattr;
> -	struct module_kobject *mk;
> -	int err;
> -
> -	for (vattr = __start___modver; vattr < __stop___modver; vattr++) {
> -		mk = lookup_or_create_module_kobject(vattr->module_name);
> -		if (mk) {
> -			err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
> -			WARN_ON_ONCE(err);
> -			kobject_uevent(&mk->kobj, KOBJ_ADD);
> -			kobject_put(&mk->kobj);
> -		}
> -	}
> -}
> -
>  /* module-related sysfs stuff */
>  
>  static ssize_t module_attr_show(struct kobject *kobj,
> @@ -977,7 +948,6 @@ static int __init param_sysfs_builtin_init(void)
>  	if (!module_kset)
>  		return -ENOMEM;
>  
> -	version_sysfs_builtin();
>  	param_sysfs_builtin();
>  
>  	return 0;
> -- 
> 2.53.0
> 

Re: [PATCH] module: remove MODULE_VERSION()

[Sami Tolvanen]

On Fri, Mar 13, 2026 at 04:46:06PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 13, 2026 at 03:20:42PM +0100, Greg Kroah-Hartman wrote:
> > Module "versions" do not make sense as the kernel is built all at once,
> > the "version" is the overall kernel version number, so modules can not
> > really be described as having a unique version given that they rely on
> > the infrastructure of the whole kernel.
> > 
> > For now, just make this an "empty" define, to keep existing code
> > building properly as the tree is slowly purged of the use of this over
> > time.
> > 
> > This macro will be removed entirely in the future when there are no
> > in-tree users.
> > 
> > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > Cc: Petr Pavlu <petr.pavlu@suse.com>
> > Cc: Daniel Gomez <da.gomez@kernel.org>
> > Cc: Sami Tolvanen <samitolvanen@google.com>
> > Cc: Aaron Tomlin <atomlin@atomlin.com>
> > Cc: Shyam Saini <shyamsaini@linux.microsoft.com>
> > Cc: Kees Cook <kees@kernel.org>
> > Cc: Thorsten Blum <thorsten.blum@linux.dev>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> >  include/linux/module.h | 56 +++++++++---------------------------------
> >  kernel/params.c        | 30 ----------------------
> >  2 files changed, 11 insertions(+), 75 deletions(-)
> 
> 
> Sami just pointed out to me off-list that maybe I should also drop the
> srcversion stuff too.  I'll gladly do that too, does anyone know if
> anyone even uses that anymore?

Looks like a lof of distributions enable MODULE_SRCVERSION_ALL, but
I'm not sure if they actually depend on the feature:

https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=MODULE_SRCVERSION_ALL

Sami

Re: [PATCH] module: remove MODULE_VERSION()

[Christophe Leroy (CS GROUP)]

Le 13/03/2026 à 16:46, Greg Kroah-Hartman a écrit :
> On Fri, Mar 13, 2026 at 03:20:42PM +0100, Greg Kroah-Hartman wrote:
>> Module "versions" do not make sense as the kernel is built all at once,
>> the "version" is the overall kernel version number, so modules can not
>> really be described as having a unique version given that they rely on
>> the infrastructure of the whole kernel.
>>
>> For now, just make this an "empty" define, to keep existing code
>> building properly as the tree is slowly purged of the use of this over
>> time.
>>
>> This macro will be removed entirely in the future when there are no
>> in-tree users.
>>
>> Cc: Luis Chamberlain <mcgrof@kernel.org>
>> Cc: Petr Pavlu <petr.pavlu@suse.com>
>> Cc: Daniel Gomez <da.gomez@kernel.org>
>> Cc: Sami Tolvanen <samitolvanen@google.com>
>> Cc: Aaron Tomlin <atomlin@atomlin.com>
>> Cc: Shyam Saini <shyamsaini@linux.microsoft.com>
>> Cc: Kees Cook <kees@kernel.org>
>> Cc: Thorsten Blum <thorsten.blum@linux.dev>
>> Cc: Christoph Hellwig <hch@infradead.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>>   include/linux/module.h | 56 +++++++++---------------------------------
>>   kernel/params.c        | 30 ----------------------
>>   2 files changed, 11 insertions(+), 75 deletions(-)
> 
> 
> Sami just pointed out to me off-list that maybe I should also drop the
> srcversion stuff too.  I'll gladly do that too, does anyone know if
> anyone even uses that anymore?

If I understand correctly the text in kernel/module/Kconfig, srcversion 
is added only for modules which contain a MODULE_VERSION.

So as you drop MODULE_VERSION, srcversion becomes completely useless 
doesn't it ?

Christophe

Re: [PATCH] module: remove MODULE_VERSION()

[Christoph Hellwig]

On Sat, Mar 14, 2026 at 11:22:22AM +0100, Christophe Leroy (CS GROUP) wrote:
> > Sami just pointed out to me off-list that maybe I should also drop the
> > srcversion stuff too.  I'll gladly do that too, does anyone know if
> > anyone even uses that anymore?
> 
> If I understand correctly the text in kernel/module/Kconfig, srcversion is
> added only for modules which contain a MODULE_VERSION.
> 
> So as you drop MODULE_VERSION, srcversion becomes completely useless doesn't
> it ?

Looks like it.

Re: [PATCH] module: remove MODULE_VERSION()

[Sami Tolvanen]

On Mon, Mar 16, 2026 at 01:58:41AM -0700, Christoph Hellwig wrote:
> On Sat, Mar 14, 2026 at 11:22:22AM +0100, Christophe Leroy (CS GROUP) wrote:
> > > Sami just pointed out to me off-list that maybe I should also drop the
> > > srcversion stuff too.  I'll gladly do that too, does anyone know if
> > > anyone even uses that anymore?
> > 
> > If I understand correctly the text in kernel/module/Kconfig, srcversion is
> > added only for modules which contain a MODULE_VERSION.
> > 
> > So as you drop MODULE_VERSION, srcversion becomes completely useless doesn't
> > it ?
> 
> Looks like it.

Looking at modpost, srcversions are added to all modules if
MODULE_SRCVERSION_ALL is enabled, whether they have MODULE_VERSION or
not. Doesn't mean it's not completely useless, of course.

Sami

Re: [PATCH] module: remove MODULE_VERSION()

[Petr Pavlu]

On 3/13/26 4:46 PM, Greg Kroah-Hartman wrote:
> On Fri, Mar 13, 2026 at 03:20:42PM +0100, Greg Kroah-Hartman wrote:
>> Module "versions" do not make sense as the kernel is built all at once,
>> the "version" is the overall kernel version number, so modules can not
>> really be described as having a unique version given that they rely on
>> the infrastructure of the whole kernel.
>>
>> For now, just make this an "empty" define, to keep existing code
>> building properly as the tree is slowly purged of the use of this over
>> time.
>>
>> This macro will be removed entirely in the future when there are no
>> in-tree users.
>>
>> Cc: Luis Chamberlain <mcgrof@kernel.org>
>> Cc: Petr Pavlu <petr.pavlu@suse.com>
>> Cc: Daniel Gomez <da.gomez@kernel.org>
>> Cc: Sami Tolvanen <samitolvanen@google.com>
>> Cc: Aaron Tomlin <atomlin@atomlin.com>
>> Cc: Shyam Saini <shyamsaini@linux.microsoft.com>
>> Cc: Kees Cook <kees@kernel.org>
>> Cc: Thorsten Blum <thorsten.blum@linux.dev>
>> Cc: Christoph Hellwig <hch@infradead.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>>  include/linux/module.h | 56 +++++++++---------------------------------
>>  kernel/params.c        | 30 ----------------------
>>  2 files changed, 11 insertions(+), 75 deletions(-)
> 
> 
> Sami just pointed out to me off-list that maybe I should also drop the
> srcversion stuff too.  I'll gladly do that too, does anyone know if
> anyone even uses that anymore?

Despite its name, I believe srcversion is primarily used to identify
binaries. Nowadays, modules contain build IDs, which is a standard
mechanism for this. The information is available already via
/sys/module/<module>/notes/.note.gnu.build-id, so removing the
srcversion data makes sense to me.

-- 
Thanks,
Petr

Re: [PATCH] module: remove MODULE_VERSION()

[Sami Tolvanen]

Hi Greg,

On Fri, Mar 13, 2026 at 03:20:42PM +0100, Greg Kroah-Hartman wrote:
> Module "versions" do not make sense as the kernel is built all at once,
> the "version" is the overall kernel version number, so modules can not
> really be described as having a unique version given that they rely on
> the infrastructure of the whole kernel.
> 
> For now, just make this an "empty" define, to keep existing code
> building properly as the tree is slowly purged of the use of this over
> time.
> 
> This macro will be removed entirely in the future when there are no
> in-tree users.
> 
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Daniel Gomez <da.gomez@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Aaron Tomlin <atomlin@atomlin.com>
> Cc: Shyam Saini <shyamsaini@linux.microsoft.com>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Thorsten Blum <thorsten.blum@linux.dev>
> Cc: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  include/linux/module.h | 56 +++++++++---------------------------------
>  kernel/params.c        | 30 ----------------------
>  2 files changed, 11 insertions(+), 75 deletions(-)

This certainly solves our version problems! I noticed there are a
couple of __modver references left in the code base after this patch,
which can be dropped too, and you can also remove the version field
from struct module at the same time.

Sami

Re: [PATCH] module: remove MODULE_VERSION()

[Christoph Hellwig]

On Fri, Mar 13, 2026 at 03:20:42PM +0100, Greg Kroah-Hartman wrote:
> Module "versions" do not make sense as the kernel is built all at once,
> the "version" is the overall kernel version number, so modules can not
> really be described as having a unique version given that they rely on
> the infrastructure of the whole kernel.
> 
> For now, just make this an "empty" define, to keep existing code
> building properly as the tree is slowly purged of the use of this over
> time.
> 
> This macro will be removed entirely in the future when there are no
> in-tree users.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

The removal should be an easy scriptable one after the next -rc1.

Re: [PATCH] module: remove MODULE_VERSION()

[Petr Pavlu]

On 3/13/26 3:20 PM, Greg Kroah-Hartman wrote:
> Module "versions" do not make sense as the kernel is built all at once,
> the "version" is the overall kernel version number, so modules can not
> really be described as having a unique version given that they rely on
> the infrastructure of the whole kernel.
> 
> For now, just make this an "empty" define, to keep existing code
> building properly as the tree is slowly purged of the use of this over
> time.
> 
> This macro will be removed entirely in the future when there are no
> in-tree users.

I share a similar sentiment that module versions set by MODULE_VERSION()
are not particularly useful for in-tree modules and the macro is often
used unnecessarily. However, I don't think this patch takes the best
approach to phase it out.

The file Documentation/ABI/stable/sysfs-module documents
/sys/module/<MODULENAME>/version as a stable ABI. Searching for
'^MODULE_VERSION' in v7.0-rc4 shows 600 uses of the macro. My concern is
that if any of these modules has a userspace part that checks the
version, this patch could potentially break users' systems.

I believe it would be safer to start by removing individual uses of
MODULE_VERSION(). That way, we can also learn if we're missing any use
cases for having module versions.

The original patch "Add a MODULE_VERSION macro" [1] from 2004 doesn't
say much about the motivation for adding module versions, but it does
mention that they should be accessible via sysfs. That was implemented
a year later in commit c988d2b28454 ("[PATCH] modules: add version and
srcversion to sysfs") [2], which primarily discusses use cases related
to DKMS, and to administrators + tech support needing to know what is
actually loaded on the system. For the latter, I believe srcversion (or
something similar) should be sufficient.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=466ae11966ae380eb5e10cdf323e140d824fa10c
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c988d2b2845495373f666a381d354a7f80981d62

-- 
Thanks,
Petr

Re: [PATCH] module: remove MODULE_VERSION()

[Greg Kroah-Hartman]

On Mon, Mar 16, 2026 at 10:37:38AM +0100, Petr Pavlu wrote:
> On 3/13/26 3:20 PM, Greg Kroah-Hartman wrote:
> > Module "versions" do not make sense as the kernel is built all at once,
> > the "version" is the overall kernel version number, so modules can not
> > really be described as having a unique version given that they rely on
> > the infrastructure of the whole kernel.
> > 
> > For now, just make this an "empty" define, to keep existing code
> > building properly as the tree is slowly purged of the use of this over
> > time.
> > 
> > This macro will be removed entirely in the future when there are no
> > in-tree users.
> 
> I share a similar sentiment that module versions set by MODULE_VERSION()
> are not particularly useful for in-tree modules and the macro is often
> used unnecessarily. However, I don't think this patch takes the best
> approach to phase it out.
> 
> The file Documentation/ABI/stable/sysfs-module documents
> /sys/module/<MODULENAME>/version as a stable ABI. Searching for
> '^MODULE_VERSION' in v7.0-rc4 shows 600 uses of the macro. My concern is
> that if any of these modules has a userspace part that checks the
> version, this patch could potentially break users' systems.

sysfs use is ALWAYS "if the file is not there, the userspace tool should
keep working".  How would userspace every do something different if a
module version flag is not there, that is not how a kernel driver should
ever be attempting to communicate with userspace as to what the api is,
or is not.

And as the module version does not even work for any stable kernel
release, it's kind of proof that userspace does not rely on this.

> I believe it would be safer to start by removing individual uses of
> MODULE_VERSION(). That way, we can also learn if we're missing any use
> cases for having module versions.

Sure, I'll make up a patch to drop all 700 uses, but how is that much
different?  :)

> The original patch "Add a MODULE_VERSION macro" [1] from 2004 doesn't
> say much about the motivation for adding module versions, but it does
> mention that they should be accessible via sysfs.

That was because we were just exporting all of the module information in
sysfs, not due to us attempting to do anything special with that info in
userspace other than "hey we have an attribute, let's export it!"

> That was implemented
> a year later in commit c988d2b28454 ("[PATCH] modules: add version and
> srcversion to sysfs") [2], which primarily discusses use cases related
> to DKMS, and to administrators + tech support needing to know what is
> actually loaded on the system. For the latter, I believe srcversion (or
> something similar) should be sufficient.

And does dkms actually do anything with this sysfs value?  At quick
glance, I couldn't see anything.

thanks,

greg k-h

Re: [PATCH] module: remove MODULE_VERSION()

[Petr Pavlu]

On 3/16/26 11:03 AM, Greg Kroah-Hartman wrote:
> On Mon, Mar 16, 2026 at 10:37:38AM +0100, Petr Pavlu wrote:
>> On 3/13/26 3:20 PM, Greg Kroah-Hartman wrote:
>>> Module "versions" do not make sense as the kernel is built all at once,
>>> the "version" is the overall kernel version number, so modules can not
>>> really be described as having a unique version given that they rely on
>>> the infrastructure of the whole kernel.
>>>
>>> For now, just make this an "empty" define, to keep existing code
>>> building properly as the tree is slowly purged of the use of this over
>>> time.
>>>
>>> This macro will be removed entirely in the future when there are no
>>> in-tree users.
>>
>> I share a similar sentiment that module versions set by MODULE_VERSION()
>> are not particularly useful for in-tree modules and the macro is often
>> used unnecessarily. However, I don't think this patch takes the best
>> approach to phase it out.
>>
>> The file Documentation/ABI/stable/sysfs-module documents
>> /sys/module/<MODULENAME>/version as a stable ABI. Searching for
>> '^MODULE_VERSION' in v7.0-rc4 shows 600 uses of the macro. My concern is
>> that if any of these modules has a userspace part that checks the
>> version, this patch could potentially break users' systems.
> 
> sysfs use is ALWAYS "if the file is not there, the userspace tool should
> keep working".  How would userspace every do something different if a
> module version flag is not there, that is not how a kernel driver should
> ever be attempting to communicate with userspace as to what the api is,
> or is not.
> 
> And as the module version does not even work for any stable kernel
> release, it's kind of proof that userspace does not rely on this.

Makes sense. I have now also reviewed updates of MODULE_VERSION()
invocations going back 5 years and my impression is that removing this
macro should be generally safe.

New instances of MODULE_VERSION() are typically introduced when a new
driver is added to the codebase.

There were numerous commits where MODULE_VERSION() is removed with the
argument that it is unnecessary for in-tree modules and that the main
kernel version should be used instead. This suggest that there is
already a broader consensus that module versions are not particularly
useful, at least not for in-tree modules.

There was a limited number of cases where a per-module version is
actually updated. Examples:

ea7af9454815 ("platform/x86: dell_rbu: Bump version")
93d09773d1a5 ("xz: add RISC-V BCJ filter")
98d5b61ef5fa ("coda: bump module version to 7.2")
8cb5d216ab33 ("char: xillybus: Move class-related functions to new xillybus_class.c")
74f46a0524f8 ("scsi: fnic: Turn off FDMI ACTIVE flags on link down")
6cd379f75f42 ("ata: pata_hpt3x2n: pass base DPLL frequency to hpt3x2n_pci_clock()")
47adef20e67d ("pata: ixp4xx: Rewrite to use device tree")

(The last three commits are indirect updates, where the module contains
MODULE_VERSION(DRV_VERSION); and DRV_VERSION is updated.)

Most of these version bumps do not seem particularly noteworthy. Only
commit 98d5b61ef5fa appears somewhat interesting with the description:

    coda: bump module version to 7.2

    Helps with tracking which patches have been propagated upstream and if
    users are running the latest known version.

> 
>> I believe it would be safer to start by removing individual uses of
>> MODULE_VERSION(). That way, we can also learn if we're missing any use
>> cases for having module versions.
> 
> Sure, I'll make up a patch to drop all 700 uses, but how is that much
> different?  :)

The end result is ultimately the same. The kernel will no longer have
any uses of MODULE_VERSION() or its implementation.

The difference is that by removing the uses of MODULE_VERSION() first,
the maintainers of the relevant code will be properly informed about
this change, rather than being told afterwards, when they will no longer
have a chance to provide any feedback.

Another aspect is that MODULE_VERSION() still appears useful for
external modules. Sure, we won't keep this macro if all uses in the
kernel are removed and these external modules will need to replace it
with a different mechanism. However, changing MODULE_VERSION() now to
only a dummy implementation can silently break version tracking for
these modules, which is not ideal.

If I end up being the only one who prefers removing the invocations of
this macro first, then please at least CC a few more lists on v2 of the
patch, such as driver-core and netdev, as well as the authors of the
recent version-bump commits that I identified above.

> 
>> The original patch "Add a MODULE_VERSION macro" [1] from 2004 doesn't
>> say much about the motivation for adding module versions, but it does
>> mention that they should be accessible via sysfs.
> 
> That was because we were just exporting all of the module information in
> sysfs, not due to us attempting to do anything special with that info in
> userspace other than "hey we have an attribute, let's export it!"
> 
>> That was implemented
>> a year later in commit c988d2b28454 ("[PATCH] modules: add version and
>> srcversion to sysfs") [2], which primarily discusses use cases related
>> to DKMS, and to administrators + tech support needing to know what is
>> actually loaded on the system. For the latter, I believe srcversion (or
>> something similar) should be sufficient.
> 
> And does dkms actually do anything with this sysfs value?  At quick
> glance, I couldn't see anything.

I'm not familiar with DKMS. From a quick look, it parses both the
version and srcversion, although it calls modinfo and doesn't read the
values from sysfs. See get_module_verinfo() and compare_module_version()
in dkms.in [1].

[1] https://github.com/dkms-project/dkms/blob/2c35ae1d32eb6377ef8e8dd7e15427d56b63828d/dkms.in#L983

-- 
Thanks,
Petr

Re: [PATCH] module: remove MODULE_VERSION()

[Nam Cao]

Petr Pavlu <petr.pavlu@suse.com> writes:
> On 3/13/26 3:20 PM, Greg Kroah-Hartman wrote:
>> Module "versions" do not make sense as the kernel is built all at once,
>> the "version" is the overall kernel version number, so modules can not
>> really be described as having a unique version given that they rely on
>> the infrastructure of the whole kernel.
>> 
>> For now, just make this an "empty" define, to keep existing code
>> building properly as the tree is slowly purged of the use of this over
>> time.
>> 
>> This macro will be removed entirely in the future when there are no
>> in-tree users.
...
> The original patch "Add a MODULE_VERSION macro" [1] from 2004 doesn't
> say much about the motivation for adding module versions, but it does
> mention that they should be accessible via sysfs. That was implemented
> a year later in commit c988d2b28454 ("[PATCH] modules: add version and
> srcversion to sysfs") [2], which primarily discusses use cases related
> to DKMS, and to administrators + tech support needing to know what is
> actually loaded on the system. For the latter, I believe srcversion (or
> something similar) should be sufficient.

I develop an external module. And our userspace program does rely on
this to get the module's version on the user's system. This patch would
break our program.

I can change to use a different mechanism. But surely I am not the only
one who write something that rely on this.

Best regards,
Nam

Re: [PATCH] module: remove MODULE_VERSION()

[Greg Kroah-Hartman]

On Fri, Mar 27, 2026 at 01:27:26PM +0100, Nam Cao wrote:
> Petr Pavlu <petr.pavlu@suse.com> writes:
> > On 3/13/26 3:20 PM, Greg Kroah-Hartman wrote:
> >> Module "versions" do not make sense as the kernel is built all at once,
> >> the "version" is the overall kernel version number, so modules can not
> >> really be described as having a unique version given that they rely on
> >> the infrastructure of the whole kernel.
> >> 
> >> For now, just make this an "empty" define, to keep existing code
> >> building properly as the tree is slowly purged of the use of this over
> >> time.
> >> 
> >> This macro will be removed entirely in the future when there are no
> >> in-tree users.
> ...
> > The original patch "Add a MODULE_VERSION macro" [1] from 2004 doesn't
> > say much about the motivation for adding module versions, but it does
> > mention that they should be accessible via sysfs. That was implemented
> > a year later in commit c988d2b28454 ("[PATCH] modules: add version and
> > srcversion to sysfs") [2], which primarily discusses use cases related
> > to DKMS, and to administrators + tech support needing to know what is
> > actually loaded on the system. For the latter, I believe srcversion (or
> > something similar) should be sufficient.
> 
> I develop an external module. And our userspace program does rely on
> this to get the module's version on the user's system. This patch would
> break our program.

Why not get the module merged upstream so you don't have this problem
anymore?

> I can change to use a different mechanism. But surely I am not the only
> one who write something that rely on this.

I recommend changing it, as this is not needed in the tree :)

I've been at a conference all week, will respin this patch series next
week and resend, sorry for the delay.

thanks,

greg k-h