From: "Ahmed S. Darwish" <a.darwish@linutronix.de>
To: peterz@infradead.org
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Sebastian A. Siewior" <bigeasy@linutronix.de>,
"Paul E. McKenney" <paulmck@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 4/5] seqlock: seqcount_LOCKNAME_t: Introduce PREEMPT_RT support
Date: Tue, 8 Sep 2020 14:48:50 +0200 [thread overview]
Message-ID: <20200908124850.GA487635@lx-t490> (raw)
In-Reply-To: <20200908114520.GS1362448@hirez.programming.kicks-ass.net>
On Tue, Sep 08, 2020 at 01:45:20PM +0200, peterz@infradead.org wrote:
> On Fri, Sep 04, 2020 at 05:32:30PM +0200, Ahmed S. Darwish wrote:
> > @@ -406,13 +443,20 @@ static inline int read_seqcount_t_retry(const seqcount_t *s, unsigned start)
> > return __read_seqcount_t_retry(s, start);
> > }
> >
> > +/*
> > + * Enforce non-preemptibility for all seqcount_LOCKNAME_t writers. Don't
> > + * do it for PREEMPT_RT, for the reasons outlined at __SEQ_LOCK().
> > + */
> > +#define __seq_enforce_writer_non_preemptibility(s) \
> > + (!IS_ENABLED(CONFIG_PREEMPT_RT) && __seqcount_lock_preemptible(s))
> > +
> > /**
> > * raw_write_seqcount_begin() - start a seqcount_t write section w/o lockdep
> > * @s: Pointer to seqcount_t or any of the seqcount_LOCKNAME_t variants
> > */
> > #define raw_write_seqcount_begin(s) \
> > do { \
> > - if (__seqcount_lock_preemptible(s)) \
> > + if (__seq_enforce_writer_non_preemptibility(s)) \
> > preempt_disable(); \
> > \
> > raw_write_seqcount_t_begin(__seqcount_ptr(s)); \
> > @@ -433,7 +477,7 @@ static inline void raw_write_seqcount_t_begin(seqcount_t *s)
> > do { \
> > raw_write_seqcount_t_end(__seqcount_ptr(s)); \
> > \
> > - if (__seqcount_lock_preemptible(s)) \
> > + if (__seq_enforce_writer_non_preemptibility(s)) \
> > preempt_enable(); \
> > } while (0)
> >
> > @@ -456,7 +500,7 @@ static inline void raw_write_seqcount_t_end(seqcount_t *s)
> > do { \
> > __seqcount_assert_lock_held(s); \
> > \
> > - if (__seqcount_lock_preemptible(s)) \
> > + if (__seq_enforce_writer_non_preemptibility(s)) \
> > preempt_disable(); \
> > \
> > write_seqcount_t_begin_nested(__seqcount_ptr(s), subclass); \
> > @@ -483,7 +527,7 @@ static inline void write_seqcount_t_begin_nested(seqcount_t *s, int subclass)
> > do { \
> > __seqcount_assert_lock_held(s); \
> > \
> > - if (__seqcount_lock_preemptible(s)) \
> > + if (__seq_enforce_writer_non_preemptibility(s)) \
> > preempt_disable(); \
> > \
> > write_seqcount_t_begin(__seqcount_ptr(s)); \
> > @@ -504,7 +548,7 @@ static inline void write_seqcount_t_begin(seqcount_t *s)
> > do { \
> > write_seqcount_t_end(__seqcount_ptr(s)); \
> > \
> > - if (__seqcount_lock_preemptible(s)) \
> > + if (__seq_enforce_writer_non_preemptibility(s)) \
> > preempt_enable(); \
> > } while (0)
>
> I've replaced the above with the below, afaict there were no users of
> __seqcount_lock_preemptible() left.
>
> --- a/include/linux/seqlock.h
> +++ b/include/linux/seqlock.h
> @@ -228,7 +228,11 @@ __seqprop_##lockname##_sequence(const se
> static __always_inline bool \
> __seqprop_##lockname##_preemptible(const seqcount_##lockname##_t *s) \
> { \
> - return preemptible; \
> + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) \
> + return preemptible; \
> + \
> + /* PREEMPT_RT relies on the above LOCK+UNLOCK */ \
> + return false; \
> } \
> \
Sounds good.
next prev parent reply other threads:[~2020-09-08 17:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 15:32 [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support Ahmed S. Darwish
2020-09-04 15:32 ` [PATCH v2 1/5] seqlock: seqcount_LOCKNAME_t: Standardize naming convention Ahmed S. Darwish
2020-09-10 15:08 ` [tip: locking/core] " tip-bot2 for Ahmed S. Darwish
2020-09-04 15:32 ` [PATCH v2 2/5] seqlock: Use unique prefix for seqcount_t property accessors Ahmed S. Darwish
2020-09-08 11:41 ` peterz
2020-09-10 15:08 ` [tip: locking/core] " tip-bot2 for Ahmed S. Darwish
2020-09-04 15:32 ` [PATCH v2 3/5] seqlock: seqcount_t: Implement all read APIs as statement expressions Ahmed S. Darwish
2020-09-10 15:08 ` [tip: locking/core] " tip-bot2 for Ahmed S. Darwish
2020-09-04 15:32 ` [PATCH v2 4/5] seqlock: seqcount_LOCKNAME_t: Introduce PREEMPT_RT support Ahmed S. Darwish
2020-09-08 11:45 ` peterz
2020-09-08 12:48 ` Ahmed S. Darwish [this message]
2020-09-04 15:32 ` [PATCH v2 5/5] seqlock: PREEMPT_RT: Do not starve seqlock_t writers Ahmed S. Darwish
2020-09-10 15:08 ` [tip: locking/core] " tip-bot2 for Ahmed S. Darwish
2020-09-15 0:20 ` [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support Qian Cai
2020-09-15 12:48 ` Boqun Feng
2020-09-15 13:10 ` Boqun Feng
2020-09-15 14:30 ` peterz
2020-09-16 12:52 ` Qian Cai
2020-09-16 12:54 ` peterz
2020-09-16 13:00 ` Qian Cai
2020-09-16 13:02 ` peterz
2020-09-17 2:31 ` Stephen Rothwell
2020-09-18 8:42 ` [tip: locking/core] seqlock: Unbreak lockdep tip-bot2 for peterz@infradead.org
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=20200908124850.GA487635@lx-t490 \
--to=a.darwish@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).