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;
To:     Vlastimil Babka <vbabka@suse.cz>,
        John Hubbard <jhubbard@nvidia.com>,
        Miaohe Lin <linmiaohe@huawei.com>, akpm@linux-foundation.org
Cc:     iamjoonsoo.kim@lge.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <20210904091839.20270-1-linmiaohe@huawei.com>
 <3b36529f-ab97-ddfe-0407-66f0cd1fd38d@redhat.com>
 <2d06db75-5c26-8fe2-6883-ac99056a9894@redhat.com>
 <b0a2947b-360a-40c2-03e4-f0f67845f4c3@huawei.com>
 <c60dc5e2-6f19-3be8-56be-555033cc9ca4@redhat.com>
 <b4615b3c-8217-9f32-39c7-b91c9ec3cccb@suse.cz>
 <80cfffdc-227e-c045-be74-1c08fb62c1e3@redhat.com>
 <febcceaa-7d94-c3a3-c683-7a8694981b47@nvidia.com>
 <efdab0d6-199a-1bb8-79bf-ea0a5b94c093@redhat.com>
 <f9cc811d-2932-845d-da0e-eea493981d11@suse.cz>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
Subject: Re: [PATCH] mm/page_isolation: don't putback unisolated page
Message-ID: <924b4672-0e52-56fb-22a9-b02d8c3ecccf@redhat.com>
Date:   Thu, 9 Sep 2021 11:37:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <f9cc811d-2932-845d-da0e-eea493981d11@suse.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 09.09.21 11:07, Vlastimil Babka wrote:
> On 9/9/21 10:56, David Hildenbrand wrote:
>> On 09.09.21 00:42, John Hubbard wrote:
>>> On 9/7/21 2:56 AM, David Hildenbrand wrote:
>>> ...
>>>>> If this can be handled gracefully, then I'd rather go with VM_WARN_ON.
>>>>> Maybe even WARN_ON_ONCE?
>>>>>
>>>>
>>>> I think either VM_BUG_ON() or VM_WARN_ON() -- compiling the runtime
>>>> checks out -- should be good
>>>> enough.
>>>>
>>>> I'd just go with VM_BUG_ON(), because anybody messing with
>>>> __isolate_free_page() should clearly spot
>>>> that we expect the current handling. But no strong opinion.
>>>>
>>>
>>> If in doubt, WARN*() should be preferred over BUG*(). There's a pretty long
>>> history of "don't kill the machine unless you have to" emails about this, let
>>> me dig up one...OK, maybe not the best example, but the tip of the iceberg:
>>
>> Please note the subtle difference between BUG_ON and VM_BUG_ON. We expect
>> VM_BUG_ON to be compiled out on any production system. So it's really only a
>> mean to identify things that really shouldn't be like that during
>> debugging/testing.
> 
> IIRC Fedora used to have CONFIG_DEBUG_VM enabled, did it change?

Excellent question. Apparently you are right. Fortunately it's not a 
distro to use in production ;)

In kernel-ark:

redhat/configs/fedora/generic/CONFIG_DEBUG_VM:CONFIG_DEBUG_VM=y

While for ARK (rhel-next so to say)

redhat/configs/ark/generic/CONFIG_DEBUG_VM:# CONFIG_DEBUG_VM is not set

So yes, the VM_WARN_ON would then be preferred in that case. But it's 
something that should never ever happen unless reviewers and developers 
really mess up, so I don't actually would sleep over that. We have other 
WARN... that can trigger more easily.

> 
>> Using WARN... instead of VM_BUG_ON is even worse for production systems.
>> There are distros that set panic_on_warn, essentially converting WARN...
>> into BUG...
> 
> Uh, does any distro really do that?

Apparently, so I was told by Greg a year ago or so when wanting to add 
WARN_ON(). The advisory is to us pr_warn_once() instead. I rememebr it 
was a debian based distro.


-- 
Thanks,

David / dhildenb