[PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave()

Oleg Nesterov posted 4 patches 4 months ago
There is a newer version of this series
fs/proc/array.c         |  9 ++------
fs/proc/base.c          | 10 ++------
include/linux/seqlock.h | 61 +++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sched/cputime.c  | 15 +++---------
4 files changed, 68 insertions(+), 27 deletions(-)
[PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave()
Posted by Oleg Nesterov 4 months ago
OK, please see V2. scoped_seqlock_read_irqsave() uses the
"for (struct {} s ..." hack to make "ulong flags" local.

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

I've dropped 5/5 which changed __dentry_path() for now.

Oleg.

 fs/proc/array.c         |  9 ++------
 fs/proc/base.c          | 10 ++------
 include/linux/seqlock.h | 61 +++++++++++++++++++++++++++++++++++++++++++++++++
 kernel/sched/cputime.c  | 15 +++---------
 4 files changed, 68 insertions(+), 27 deletions(-)
Re: [PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave()
Posted by Linus Torvalds 4 months ago
On Tue, 7 Oct 2025 at 07:22, Oleg Nesterov <oleg@redhat.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
Re: [PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave()
Posted by Oleg Nesterov 4 months ago
On 10/07, Linus Torvalds wrote:
>
> On Tue, 7 Oct 2025 at 07:22, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > 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.

OK, agreed, will do tomorrow,

> And it would allow making 'lockless' an actual 'bool'

Yeees... This will slightly increase the "size" of defines, but I
guess this doesn't really matter in this case.

Thanks,

Oleg.