linux-kernel - Re: [PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read

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: <CAHk-=wgSSr=Ljm0rJ_zV8v__uuQOHs2Z0bwQ5HRQN3H63MLQbg@mail.gmail.com>
Date: Tue, 7 Oct 2025 08:38:32 -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 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave()

On Tue, 7 Oct 2025 at 07:22, Oleg Nesterov <oleg@...hat.com> wrote:
>
> OK, please see V2. scoped_seqlock_read_irqsave() uses the
> "for (struct {} s ..." hack to make "ulong flags" local.

Well, patches 2-4 certainly look pretty. That's clearly a *much* nicer
interface.

The macros to introduce that nicer interface may not be winning any
beauty contests, but hey, that's pretty much par for the course.

So this does look like a clear improvement to the interface.

> I can change scoped_seqlock_read() to do the same, to make
> it symmetric with _irqsave() if you think it makes sense.

I don't think it's visible to users, but maybe it would make the
macros look slightly cleaner.

And it would allow making 'lockless' an actual 'bool' - which you
admittedly didn't actually do in the irqsave version either. Not that
that would matter either - I don't think compilers would care one way
or the other.

So a matter of taste. I'd personally lean towards doing it just to
make that 'use a struct in a for-loop' pattern less of an outlier, and
perhaps make people more aware of it.

For example, one advantage of doing it that way was that you only
needed one single use of __UNIQUE_ID() in the
scoped_seqlock_read_irqsave(), because the only ID that ends up being
unique is the name of the struct, and then you can have multiple
different members. I hadn't even thought of that detail, but I thought
it was a nice bonus.

But I really don't think it *matters*, so I'm happy either way.

          Linus