[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNPws3_sODe3_KcHp9UFx79xk4Ow0QvVxYHGf_axGdoEag@mail.gmail.com>
Date: Tue, 5 Nov 2024 10:28:50 +0100
From: Marco Elver <elver@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>, "Paul E. McKenney" <paulmck@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, Mark Rutland <mark.rutland@....com>,
Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/5] kcsan, seqlock: Fix incorrect assumption in read_seqbegin()
On Tue, 5 Nov 2024 at 10:13, Peter Zijlstra <peterz@...radead.org> wrote:
> > static inline unsigned read_seqretry(const seqlock_t *sl, unsigned start)
> > {
> > - /*
> > - * Assume not nested: read_seqretry() may be called multiple times when
> > - * completing read critical section.
> > - */
> > - kcsan_flat_atomic_end();
> > -
> > return read_seqcount_retry(&sl->seqcount, start);
> > }
>
> OK, so this takes us back to kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX)
> and kcsan_atomic_next(0).
>
> Which I suppose is safe, except it doesn't nest properly.
Yes correct - we just give up on trying to be special here. It would
be nice to also have readers have a clear critical section, but that
seems a lot harder to enforce with a bunch of them having rather
convoluted control flow. :-/
> Anyway, these all look really nice, let me go queue them up.
Many thanks!
Powered by blists - more mailing lists