Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2 2/2] linux/bits.h: Add compile time sanity check of
 GENMASK inputs
To:     Joe Perches <joe@perches.com>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Rikard Falkeborn <rikard.falkeborn@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Johannes Berg <johannes@sipsolutions.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20190731190309.19909-1-rikard.falkeborn@gmail.com>
 <20190801230358.4193-1-rikard.falkeborn@gmail.com>
 <20190801230358.4193-2-rikard.falkeborn@gmail.com>
 <20190807142728.GA16360@roeck-us.net>
 <CAK7LNATGuO0D0a-sTvWw5Pzkn5C7jrLiS=rCwiRsEqaS86KbuQ@mail.gmail.com>
 <099e07d4b4ecca9798404b95dc78c89bc3dd9f7f.camel@perches.com>
 <c4157db4-dbda-5ab1-2092-83c4a3b0f19e@roeck-us.net>
 <f469bc5c8ae2386af57296df0a8a17b7c223a476.camel@perches.com>
From:   Guenter Roeck <linux@roeck-us.net>
Message-ID: <860ad052-a6b9-e803-67d3-dc388e506684@roeck-us.net>
Date:   Wed, 7 Aug 2019 18:53:18 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <f469bc5c8ae2386af57296df0a8a17b7c223a476.camel@perches.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 8/7/19 6:08 PM, Joe Perches wrote:
> On Wed, 2019-08-07 at 17:58 -0700, Guenter Roeck wrote:
>> On 8/7/19 5:07 PM, Joe Perches wrote:
>>> On Wed, 2019-08-07 at 23:55 +0900, Masahiro Yamada wrote:
>>>> On Wed, Aug 7, 2019 at 11:27 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>> []
>>>>> Who is going to fix the fallout ? For example, arm64:defconfig no longer
>>>>> compiles with this patch applied.
>>>>>
>>>>> It seems to me that the benefit of catching misuses of GENMASK is much
>>>>> less than the fallout from no longer compiling kernels, since those
>>>>> kernels won't get any test coverage at all anymore.
>>>>
>>>> We cannot apply this until we fix all errors.
>>>> I do not understand why Andrew picked up this so soon.
>>>
>>> I think it makes complete sense to break -next (not mainline)
>>> and force people to fix defects.  Especially these types of
>>> defects that are trivial to fix.
>>>
>>
>> I don't think this (from next-20190807):
>>
>> Build results:
>> 	total: 158 pass: 137 fail: 21
>> Qemu test results:
>> 	total: 391 pass: 318 fail: 73
>>
>> is very useful. The situation is bad enough for newly introduced problems.
>> It is all but impossible to get fixes for all problems discovered (or introduced)
>> by adding checks like this one. In some cases, no one will care. In others,
>> no one will pick up patches. Sometimes people won't know or realize that
>> they are expected to fix something. Making the situation worse, the failures
>> introduced by the new checks will hide other accumulating problems.
>>
>> arch/sh has failed to build in mainline since 7/27 and in -next since
>> next-20190711, due to the added "fallthrough" warning. I don't think
>> that is too useful either. Ok, that situation may be a sign that the
>> architecture isn't maintained as well as it should, but I don't think
>> that this warrants breaking it on purpose in the hope to trigger
>> some kind of reaction.
>>
>> I don't mind if new checks are introduced, and I agree that it is useful
>> and makes sense. But the checks should only be introduced after a reasonable
>> attempt was made to fix _all_ associated problems. That doesn't mean that
>> the entire work has to be done by the person introducing the check, but I
>> do see that person responsible for making sure (or a reasonable definition
>> of "make sure") that all problems are fixed before actually introducing
>> the check. Yes, I understand, this is a lot of work, but adding checks
>> and letting all hell break loose can not be the answer.
> 
> No hell is unleashed.
> 
> It's -next, an integration build, not mainline.
> 

... and the breakages introduced in -next are making it into mainline
without being fixed, as I just pointed out above. That by itself is bad.
It is much worse if the breakage is introduced on purpose.

The criteria for -next _used_ to be "ready for mainline". If breaking -next
on purpose is the new normal, no one should be surprised if it will be tested
even less than it is today.

Guenter