Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210108003035.1930475-1-willmcvicker@google.com> <20210120142526.GA3759754@infradead.org>
In-Reply-To: <20210120142526.GA3759754@infradead.org>
From:   Saravana Kannan <saravanak@google.com>
Date:   Wed, 20 Jan 2021 09:01:03 -0800
Message-ID: <CAGETcx_a1-BrPfiKT0pXMkJ2gxMCBr2SSCyNij_3+vFXVKGQoA@mail.gmail.com>
Subject: Re: [PATCH v5] modules: introduce the MODULE_SCMVERSION config
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Will McVicker <willmcvicker@google.com>,
        Jessica Yu <jeyu@kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Michal Marek <michal.lkml@markovi.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Android Kernel Team <kernel-team@android.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jan 20, 2021 at 6:26 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Jan 08, 2021 at 12:30:35AM +0000, Will McVicker wrote:
> > For example, we have a CI setup that tests new kernel changes on the
> > hikey960 and db845c devices without updating their kernel modules. When
> > these tests fail, we need to be able to identify the exact device
> > configuration the test was using. By including MODULE_SCMVERSION, we can
> > identify the exact kernel and modules' SCM versions for debugging the
> > failures.
>
> Sorry, but this still has no business in the upstream kernel as every
> change to the kernel is free to just change any API.

Sure, and this patch is making no claims one way or the other on that topic.

> That is whatever
> you test there is a completely unsupported setup.

Plenty of distributions maintain stable kernels based on LTS. We've
done that too and we are able to do LTS kernel binary updates (so
better security) without waiting around for the modules to get
updated. Keep in mind, that not all modules might be updated at the
same time either. That's something that's definitely feasible and
works.

And if the API changes, MODVERSIONS catches + CI helps catch them. And
if something slips in and things fail, we want to find out what kernel
source was used vs what module source was used to debug the problem.
This is all relevant even for in-tree modules.

> More importantly the "scmversion" of a module simply does not matter,
> as we only support modules from the kernel tree and it thus must be the
> kernel version.
> be supported.

This is all talking about only in-tree modules. If you update the
kernel vs the modules separately, the scmversion does matter. Also, by
your argument, the vermagic or srcversion properties in a module
shouldn't be there either.

> You are still trying to sneak out of tree module infrastructure in here
> with a bad cover story.  Please stop doing that.

If Will needs to maintain a downstream patch for adding out-of-tree
module support, maintaining this additional patch isn't going to
significantly increase his work. But he's trying to upstream at least
the part that's useful for upstream. This is still a real problem for
a device/board that's fully upstream. Please stop ignoring real
upstream problems just because it can also be a problem for out of
tree modules. This is not how we encourage folks to upstream their
changes.

-Saravana