Message-ID: <80cf4e9a-5d49-4bc3-8160-1b23c31d4d36@quicinc.com>
Date: Thu, 20 Feb 2025 09:31:14 -0700
From: Jeffrey Hugo <quic_jhugo@...cinc.com>
To: Nicolas Schier <n.schier@....de>
CC: Masahiro Yamada <masahiroy@...nel.org>, <linux-kbuild@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Kees Cook <kees@...nel.org>,
        Nathan
 Chancellor <nathan@...nel.org>,
        Ben Hutchings <ben@...adent.org.uk>, <regressions@...ts.linux.dev>
Subject: Re: [PATCH 3/4] kbuild: slim down package for building external
 modules

On 2/20/2025 8:54 AM, Nicolas Schier wrote:
> On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
>> On 2/20/2025 3:03 AM, Nicolas Schier wrote:
>>> On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
>>>> On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
>>>>> Exclude directories and files unnecessary for building external modules:
>>>>>
>>>>>     - include/config/  (except include/config/auto.conf)
>>>>>     - scripts/atomic/
>>>>>     - scripts/dtc/
>>>>>     - scripts/kconfig/
>>>>>     - scripts/mod/mk_elfconfig
>>>>>     - scripts/package/
>>>>>     - scripts/unifdef
>>>>>     - .config
>>>>
>>>> Please revert this (the removal of .config).
>>>>
>>>> I got some strange reports that our external module install broke, and
>>>> traced it to this change.  Our external module references the .config
>>>> because we have different logic for the build depending on if other, related
>>>> modules are present or not.
>>>>
>>>> Also, it looks like this broke DKMS for some configurations, which not only
>>>> impacts DKMS itself [1] but also downstream projects [2].
>>>>
>>>> While DKMS may be updated going forward to avoid this issue, there are
>>>> plenty of affected version out in the wild.
>>>>
>>>> Also, I haven't surveyed every distro, but it looks like Ubuntu still
>>>> packages the .config with their headers in their upcoming "Plucky" release
>>>> based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
>>>> needed/useful.
>>>>
>>>> -Jeff
>>>>
>>>> [1]: https://github.com/dell/dkms/issues/464
>>>> [2]: https://github.com/linux-surface/linux-surface/issues/1654
>>>
>>> Hi Jeff,
>>>
>>> do you know the related thread [1]?  According to the last mail, DKMS
>>> has fixed its issue already in December.
>>
>> DKMS tip might be fixed, but production versions are in various distros,
>> which are not updated.  Therefore actual users are impacted by this.
>>
>> What happened to the #1 rule of kernel, that we do not break users?
> 
> I think, Masahiro already provided valid and profound reasons for
> keeping it the way it is.  Users of run-time kernel interfaces are not
> affected by the change.  Concretely reported issues were, as far as I
> know, only a matter of specific non-official way to work with .config
> for other reasons than just building external kernel modules in the way
> it is thought to work.

I'm CCing the regressions list, which I probably should have done initially.

I'm pretty sure Linus has indicated that as soon as users start doing 
something, that becomes the "official way".  I believe your response is 
not consistent with the precedent set by Linus.

Quoting from [1]:
It’s a regression if some application or practical use case running fine 
with one Linux kernel works worse or not at all with a newer version 
compiled using a similar configuration. The “no regressions” rule 
forbids this to take place; if it happens by accident, developers that 
caused it are expected to quickly fix the issue."

As far as I understand its not acceptable to force users to change (the 
DKMS fix) or update userspace to work with a new kernel.  You could make 
a change if userspace updated, and all old versions needing the previous 
behavior were phased out of use, but we have 2 reports indicating that 
is not the case.

 From the thread you pointed out, it looks like Masahiro recommends 
${kernel_source_dir}/include/config/auto.conf as a replacement for the 
.config.  Ignoring that such a suggestion seems to violate the 
regressions rule, doing a diff of that and the .config on a 6.11 build 
(before the change we are discussing), there are many changes.  It does 
not look like that is an equivalent replacement.

Are we at an impasse?  Masahiro has not chimed in, which is quite 
disappointing.  So far, I don't think your responses justify why 
breaking users is acceptable.  This is not a security fix - the only 
justification for this change is that .config is not needed, but I argue 
that has been proven false.  It seems like I am not convincing you.

-Jeff

[1]: https://docs.kernel.org/admin-guide/reporting-regressions.html

> Kind regards,
> Nicolas
> 
>> This still needs to be reverted.
>>
>> -Jeff
>>
>>>
>>> Kind regards,
>>> Nicolas
>>>
>>> [1]: https://lore.kernel.org/linux-kbuild/CAK7LNARqEOVOzP5vdUVF0KxQBNb9xtYs-COSXXWDMpBzGaLGow@mail.gmail.com/T/#m95f48caf46357a41c1df5e038e227a01ab89dbda
>>

Powered by blists - more mailing lists