Re: [PATCH v1] mm/gup: remove (VM_)BUG_ONs

[David Hildenbrand <david@redhat.com>]

On 06.06.25 20:21, John Hubbard wrote:
> 
> 
> On 6/6/25 11:15 AM, David Hildenbrand wrote:
>> On 06.06.25 20:06, Lorenzo Stoakes wrote:
>>> On Fri, Jun 06, 2025 at 10:57:44AM -0700, John Hubbard wrote:
>>>> On 6/6/25 4:04 AM, Lorenzo Stoakes wrote:
>>>>> On Fri, Jun 06, 2025 at 12:28:28PM +0200, David Hildenbrand wrote:
>>>>>> On 06.06.25 12:19, Lorenzo Stoakes wrote:
>>>>>>> On Fri, Jun 06, 2025 at 12:13:27PM +0200, Michal Hocko wrote:
>>>>>>>> On Fri 06-06-25 11:01:18, David Hildenbrand wrote:
>>>>>>>>> On 06.06.25 10:31, Michal Hocko wrote:
>>>>>>>> [...]
>>>>> So to me the only assessment needed is 'do we want to warn on this or not?'.
>>>>>
>>>>> And as you say, really WARN_ON_ONCE() seems appropriate, because nearly always
>>>>> we will get flooded with useless information.
>>>>>
>>>>
>>>> As yet another victim of such WARN_ON() floods at times, I've followed
>>>> this thread with great interest. And after reflecting on it a bit, I believe
>>>> that, surprisingly enough, WARN_ON() is a better replacement for VM_BUG_ON()
>>>> than WARN_ON_ONCE(), because:
>>>
>>> Right, these shouldn't be happening _at all_.
>>   > > I'm easy on this point, I'd say in that case VM_WARN_ON() is the most
>>> _conservative_ approach, since these are things that must not happen, and
>>> so it's not unreasonable to fail to repress repetitions of the 'impossible'
>>> :)
>>>
>>> But I get the general point about ...WARN_ON_ONCE() avoiding floods.
>>>
>>> David, what do you think?
>>
>> Well, in this patch here I deliberately want _ONCE for the unpin sanity
>> checks. Because if they start happening (IOW, now after 5 years observed
>> for the first time?) I *absolutely don't* want to get flooded and
>> *really* figure out what is going on by seeing what else failed.
>>
>> And crashing on VM_BUG_ON() and not observing anything else was also not
>> particularly helpful :)
>>
>> Because ... they shouldn't be happening ...
>>
>> (well, it goes back to my initial point about requiring individual
>> decisions etc ...)
>>
>> Not sure what's best now in the general case, in the end I don't care
>> that much.
>>
>> Roll a dice? ;)
> 
> One last data point: I've often logged onto systems that were running
> long enough that the dmesg had long since rolled over. And this makes
> the WARN_ON_ONCE() items disappear.

I think what would be *really* helpful would be quick access to the very 
first warning that triggered. At least that's what I usually dig for ... :)

-- 
Cheers,

David / dhildenb