linux-kernel - Re: [PATCH v1] mm/gup: remove (VM_)BUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250607134214.GA158671@ziepe.ca>
Date: Sat, 7 Jun 2025 10:42:14 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: David Hildenbrand <david@...hat.com>,
	John Hubbard <jhubbard@...dia.com>, Michal Hocko <mhocko@...e.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Peter Xu <peterx@...hat.com>
Subject: Re: [PATCH v1] mm/gup: remove (VM_)BUG_ONs

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