From: Oleg Nesterov <oleg@redhat.com>
To: Boqun Feng <boqun.feng@gmail.com>,
David Howells <dhowells@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Li RongQing <lirongqing@baidu.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Waiman Long <longman@redhat.com>, Will Deacon <will@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: [RFC 2/1] seqlock: make the read_seqbegin_or_lock() API more simple and less error-prone ?
Date: Sun, 28 Sep 2025 18:20:54 +0200 [thread overview]
Message-ID: <20250928162054.GB3121@redhat.com> (raw)
In-Reply-To: <20250928161953.GA3112@redhat.com>
Another problem is that this API is error prone. Two years ago half of the
read_seqbegin_or_lock() users were buggy (they followed the wrong example
from Documentation/locking/seqlock.rst). And even if the code is mostly
correct it is very easy to add a hard-to-detect mistake, see for example
[PATCH][v3] afs: Remove erroneous seq |= 1 in volume lookup loop
https://lore.kernel.org/all/20250910084235.2630-1-lirongqing@baidu.com/
Can we improve this API?
-------------------------------------------------------------------------------
To simplify, suppose we add the new helper
static inline int need_seqretry_xxx(seqlock_t *lock, int *seq)
{
int ret = !(*seq & 1) && read_seqretry(lock, *seq);
if (ret)
++*seq; /* make this counter odd */
return ret;
}
which can be used instead of need_seqretry(). This way the users do not
need to modify "seq" in the main loop. For example, we can simplify
thread_group_cputime() as follows:
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -314,7 +314,7 @@ void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times)
struct signal_struct *sig = tsk->signal;
u64 utime, stime;
struct task_struct *t;
- unsigned int seq, nextseq;
+ unsigned int seq;
unsigned long flags;
/*
@@ -330,9 +330,8 @@ void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times)
rcu_read_lock();
/* Attempt a lockless read on the first round. */
- nextseq = 0;
+ seq = 0;
do {
- seq = nextseq;
flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
times->utime = sig->utime;
times->stime = sig->stime;
@@ -344,9 +343,7 @@ void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times)
times->stime += stime;
times->sum_exec_runtime += read_sum_exec_runtime(t);
}
- /* If lockless access failed, take the lock. */
- nextseq = 1;
- } while (need_seqretry(&sig->stats_lock, seq));
+ } while (need_seqretry_xxx(&sig->stats_lock, &seq));
done_seqretry_irqrestore(&sig->stats_lock, seq, flags);
rcu_read_unlock();
}
most (if not all) of other users can be changed the same way.
-------------------------------------------------------------------------------
Or perhaps we can even add a helper that hides all the details, something like
int xxx(seqlock_t *lock, int *seq, int lockless)
{
if (lockless) {
*seq = read_seqbegin(lock);
return 1;
}
if (*seq & 1) {
read_sequnlock_excl(lock);
return 0;
}
if (read_seqretry(lock, *seq)) {
read_seqlock_excl(lock);
*seq = 1;
return 1;
}
return 0;
}
#define __XXX(lock, seq, lockless) \
for (int lockless = 1, seq; xxx(lock, &seq, lockless); lockless = 0)
#define XXX(lock) \
__XXX(lock, __UNIQUE_ID(seq), __UNIQUE_ID(lockless))
?
This way the users can simply do:
seqlock_t sl;
void func(void)
{
XXX(&sl) {
... read-side critical section ...
}
}
using only the new XXX() helper. No need to declare/initialize seq, no need
for need_seqretry/done_seqretry.
What do you think?
Oleg.
next prev parent reply other threads:[~2025-09-28 16:22 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 16:19 [PATCH 0/1] documentation: seqlock: fix the wrong documentation of read_seqbegin_or_lock/need_seqretry Oleg Nesterov
2025-09-28 16:20 ` [PATCH 1/1] " Oleg Nesterov
2025-10-01 18:21 ` Waiman Long
2025-10-01 19:06 ` Oleg Nesterov
2025-10-01 19:24 ` Waiman Long
2025-10-01 19:34 ` Waiman Long
2025-10-02 11:01 ` Oleg Nesterov
2025-10-21 10:35 ` [tip: locking/core] " tip-bot2 for Oleg Nesterov
2025-09-28 16:20 ` Oleg Nesterov [this message]
2025-09-29 0:41 ` [????] [RFC 2/1] seqlock: make the read_seqbegin_or_lock() API more simple and less error-prone ? Li,Rongqing
2025-09-29 6:47 ` Oleg Nesterov
2025-10-01 13:02 ` Peter Zijlstra
2025-10-01 13:13 ` Oleg Nesterov
2025-10-01 13:46 ` Oleg Nesterov
2025-10-02 12:58 ` Oleg Nesterov
2025-09-30 22:09 ` David Howells
2025-10-01 11:51 ` Oleg Nesterov
2025-10-05 14:47 ` [PATCH 0/5] seqlock: introduce SEQLOCK_READ_SECTION() Oleg Nesterov
2025-10-05 14:49 ` Oleg Nesterov
2025-10-05 14:50 ` [PATCH 1/5] " Oleg Nesterov
2025-10-05 15:34 ` Linus Torvalds
2025-10-05 16:07 ` Oleg Nesterov
2025-10-05 16:35 ` Linus Torvalds
2025-10-05 14:50 ` [PATCH 2/5] seqlock: change thread_group_cputime() to use SEQLOCK_READ_SECTION() Oleg Nesterov
2025-10-05 14:50 ` [PATCH 3/5] seqlock: change do_task_stat() " Oleg Nesterov
2025-10-05 14:50 ` [PATCH 4/5] seqlock: change do_io_accounting() " Oleg Nesterov
2025-10-05 14:50 ` [PATCH 5/5] seqlock: change __dentry_path() to use __SEQLOCK_READ_SECTION() Oleg Nesterov
2025-10-05 15:48 ` Linus Torvalds
2025-10-05 15:30 ` [PATCH 0/5] seqlock: introduce SEQLOCK_READ_SECTION() Al Viro
2025-10-05 17:40 ` Oleg Nesterov
2025-10-07 14:20 ` [PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave() Oleg Nesterov
2025-10-07 14:21 ` [PATCH 1/4] " Oleg Nesterov
2025-10-07 16:35 ` Waiman Long
2025-10-07 17:18 ` Oleg Nesterov
2025-10-07 17:21 ` Waiman Long
2025-10-07 14:21 ` [PATCH 2/4] seqlock: change thread_group_cputime() to use scoped_seqlock_read_irqsave() Oleg Nesterov
2025-10-07 14:21 ` [PATCH 3/4] seqlock: change do_task_stat() " Oleg Nesterov
2025-10-07 14:21 ` [PATCH 4/4] seqlock: change do_io_accounting() " Oleg Nesterov
2025-10-07 15:38 ` [PATCH 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave() Linus Torvalds
2025-10-07 16:34 ` Oleg Nesterov
2025-10-08 12:30 ` [PATCH v2 " Oleg Nesterov
2025-10-08 12:30 ` [PATCH v2 1/4] " Oleg Nesterov
2025-10-08 12:55 ` Peter Zijlstra
2025-10-08 12:59 ` Oleg Nesterov
2025-10-08 13:54 ` Peter Zijlstra
2025-10-08 16:05 ` Linus Torvalds
2025-10-08 16:55 ` Oleg Nesterov
2025-10-09 5:31 ` Linus Torvalds
2025-10-09 7:04 ` Linus Torvalds
2025-10-09 14:37 ` Oleg Nesterov
2025-10-09 16:18 ` Linus Torvalds
2025-10-09 19:50 ` Peter Zijlstra
2025-10-09 20:11 ` Peter Zijlstra
2025-10-09 20:24 ` Linus Torvalds
2025-10-09 22:12 ` Peter Zijlstra
2025-10-09 22:55 ` Linus Torvalds
2025-10-10 8:03 ` Peter Zijlstra
2025-10-10 12:32 ` Oleg Nesterov
2025-10-10 13:14 ` Oleg Nesterov
2025-10-13 9:03 ` Peter Zijlstra
2025-10-13 11:50 ` Oleg Nesterov
2025-10-10 15:30 ` Linus Torvalds
2025-10-09 23:20 ` Peter Zijlstra
2025-10-09 23:26 ` Linus Torvalds
2025-10-21 10:35 ` [tip: locking/core] seqlock: Introduce scoped_seqlock_read() tip-bot2 for Peter Zijlstra
2025-10-08 12:30 ` [PATCH v2 2/4] seqlock: change thread_group_cputime() to use scoped_seqlock_read_irqsave() Oleg Nesterov
2025-10-21 10:35 ` [tip: locking/core] seqlock: Change thread_group_cputime() to use scoped_seqlock_read() tip-bot2 for Oleg Nesterov
2025-10-08 12:30 ` [PATCH v2 3/4] seqlock: change do_task_stat() to use scoped_seqlock_read_irqsave() Oleg Nesterov
2025-10-21 10:35 ` [tip: locking/core] seqlock: Change do_task_stat() to use scoped_seqlock_read() tip-bot2 for Oleg Nesterov
2025-10-08 12:31 ` [PATCH v2 4/4] seqlock: change do_io_accounting() to use scoped_seqlock_read_irqsave() Oleg Nesterov
2025-10-21 10:35 ` [tip: locking/core] seqlock: Change do_io_accounting() to use scoped_seqlock_read() tip-bot2 for Oleg Nesterov
2025-10-08 12:56 ` [PATCH v2 0/4] seqlock: introduce scoped_seqlock_read() and scoped_seqlock_read_irqsave() Peter Zijlstra
2025-10-08 13:13 ` Oleg Nesterov
2025-10-08 13:55 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250928162054.GB3121@redhat.com \
--to=oleg@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®