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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Jun 06, 2025 at 08:03:15PM +0100, Lorenzo Stoakes wrote:
> On Fri, Jun 06, 2025 at 07:46:52PM +0100, Lorenzo Stoakes wrote:
> > On Fri, Jun 06, 2025 at 03:42:12PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 06, 2025 at 08:23:25PM +0200, David Hildenbrand wrote:
> > > > > 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 ... :)
> > >
> > > That's basically my point, it doesn't make sense to expose two APIs to
> > > developers with a choice like this. The WARN_ON infrastructure should
> > > deal with it consistently, maybe even configurable by the admin.
> > >
> > > Keeping the first warn in a buffer is definately a good option.
> > >
> > > Otherwise how is the patch author supposed to decide which API to
> > > call in each case?
> > >
> > > Jason
> >
> > To clarify - are we talking the first instance of a specific warning, or
> > the first warning in general?
> 
> OK sorry I'm being dumb, it is -per warning- reading the thread :P
> 
> So I guess you would have the macro establish a static buffer for each instance,
> and then some interface for gathering those up and outputting them?

Honestly, that seems unnecessary, just a single buffer for the first
global warning. Maybe with a 1 min rate limit for replacement or
something.

The kernel doesn't run around spewing warnings as a general rule.

> And I guess we'd not want a new interface for this like WARN_ON_ONCE_STORED()
> because that'd be... weird and how would anyone think to use that and nearly all
> cases wouldn't.

No! Delete WARN_ON_ONCE and say the new global mechanism is good
enough to capture the first WARN_ON, everyone always uses it always
and then nobody needs to think about this anymore when writing new
code.

Jason