linux-kernel - Re: [PATCH 4/4] misc: hpilo: Update driver version

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Feb 2019 07:49:28 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jerry Hoemann <jerry.hoemann@....com>
Cc:     Matt Hsiao <matt.hsiao@....com>, linux-kernel@...r.kernel.org,
        arnd@...db.de, david.altobelli@....com, mark.rusk@....com
Subject: Re: [PATCH 4/4] misc: hpilo: Update driver version

On Thu, Feb 21, 2019 at 09:11:11PM -0700, Jerry Hoemann wrote:
> On Thu, Feb 21, 2019 at 09:32:56AM +0100, Greg KH wrote:
> ...
> > >  
> > > -MODULE_VERSION("1.5.0");
> > > +MODULE_VERSION("1.5.1");
> > 
> > This line means nothing, it should just be removed entirely.  The
> > "version" of the driver is the kernel version itself.
> 
> Hi Greg,
> 
> This doesn't hold when we do driver updates.

That doesn't matter to the in-kernel code.

> Our primary means of supporting Linux to our customers is via our
> distro partners.  While we prefer to use in distro drivers, HPE does
> from time to time deliver driver updates via the "Service Pack for
> Proliants" -- The SPP. 

That's fine, but again, does not matter to the in-kernel driver at all.

> An SPP driver update can supply an updated module without modifying
> the underlying base kernel version.  Because of this, the underlying
> kernel version number doesn't always imply the version of a module
> being used.
> 
> Even when we use only in kernel drivers, we also have the case where
> our distro partners will back port newer driver versions to an older
> distro release.  This gives the situation where an older kernel
> version can have a newer module than a newer kernel version for
> that distro.
> 
> We have found that having module version bumped when modifying the
> driver helps us identify the version module actually being used.

What happens when your driver gets backports in stable kernel updates
and those updates get merged into distro kernels?  You now have a
version that means something you do not think it means.

I understand that in your viewpoint, your driver's version means
something.  But in reality, it's only the kernel's version that means
something because your driver is just part of the overall kernel, it
does not stand alone.

Your driver is simple enough that the version number doesn't really
change often and the code doesn't either, so you haven't hit these
issues yet, but for others that have tried to manage a "which version is
this driver" when dealing with backports, stable kernels, out-of-tree
drivers, and the like, it really is meaningless.

For this reason, this macro has been removed from many subsystems
already, I forgot about "misc", I might as well sweep it and do it
there too.

If you have an out-of-tree version that you provide to distros, you are
of course free to have the "version" in there if you like, but again,
for the in-kernel version of this code, it does not matter at all.

thanks,

greg k-h