[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251008135443.GU4067720@noisy.programming.kicks-ass.net>
Date: Wed, 8 Oct 2025 15:54:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Boqun Feng <boqun.feng@...il.com>,
David Howells <dhowells@...hat.com>, Ingo Molnar <mingo@...hat.com>,
Li RongQing <lirongqing@...du.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] seqlock: introduce scoped_seqlock_read() and
scoped_seqlock_read_irqsave()
On Wed, Oct 08, 2025 at 02:59:03PM +0200, Oleg Nesterov wrote:
> On 10/08, Peter Zijlstra wrote:
> >
> > On Wed, Oct 08, 2025 at 02:30:45PM +0200, Oleg Nesterov wrote:
> > >
> > > scoped_seqlock_read_irqsave (&seqlock) {
> > > // read-side critical section
> > > }
> > >
> >
> > Hmm, on first reading I was expecting that to be:
> >
> > do {
> > seq = read_seqbegin(&seqlock);
> >
> > // read-side section
> >
> > } while (read_seqretry(&seqlock, seq));
> >
> > for lack of that _or_lock() wording, but I suppose we can make that
> > something like:
> >
> > scoped_seqbegin_read (&seqlock) {
>
> I was thinking about scoped_seqcount_read() but I agree with any naming
Ah, but that would take a seqcount_*t not a seqlock_t no?
Or we can do:
scoped_seqcount_read (&seqlock.seqcount)
But yeah, for later I suppose.
Powered by blists - more mailing lists