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

[John Hubbard]

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.



> 

thanks,
-- 
John Hubbard