[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjuoFm9yZur_T4VOnX2iyDYD6T_gDRXE5ms9538W6Q35g@mail.gmail.com>
Date: Wed, 8 Oct 2025 22:31:48 -0700
From: Linus Torvalds <torvalds@...ux-foundation.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>, Peter Zijlstra <peterz@...radead.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, 8 Oct 2025 at 09:05, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I think that you should make that helper function be a macro - so that
> it can take the unnamed union type as its argument - and then make it
> do something like this instead:
>
> #define __scoped_seqlock_read_retry(s) ({ s.lockless ? \
> (s.lockless = false) || read_seqretry(lock, s.seq) ? \
> ({ read_seqlock_excl(lock); true }) : false : \
> ({ read_sequnlock_excl(lock); false }) })
Actually, it shouldn't do that "s.lockless = false" thing at all -
because that's done by the for() loop.
So that was just a thinko from trying to translate the whole "*seq =
1" hackery from the old model.
But that hackery shouldn't even exist since it's all handled naturally
and much more cleanly by the surrounding for-loop.
The only thing that the macro needs to worry about is whether it
should retry after the lockless case (and take the lock if so), or
whether it should just unlock after the locked case.
Linus
Powered by blists - more mailing lists