From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
pmladek@suse.com, sergey.senozhatsky@gmail.com,
linux-kernel@vger.kernel.org, mingo@kernel.org,
tglx@linutronix.de
Subject: Re: [PATCH 3/3] early_printk: Add simple serialization to early_vprintk()
Date: Wed, 4 Oct 2017 07:17:45 -0700 [thread overview]
Message-ID: <20171004141745.GH3521@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171004090401.3a5123a6@gandalf.local.home>
On Wed, Oct 04, 2017 at 09:04:01AM -0400, Steven Rostedt wrote:
> On Wed, 4 Oct 2017 11:08:30 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Tue, Oct 03, 2017 at 06:24:22PM -0400, Steven Rostedt wrote:
> > > On Thu, 28 Sep 2017 14:18:26 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > > static int early_vprintk(const char *fmt, va_list args)
> > > > {
> > > > + int n, cpu, old;
> > > > char buf[512];
> > > > +
> > > > + cpu = get_cpu();
> > > > + /*
> > > > + * Test-and-Set inter-cpu spinlock with recursion.
> > > > + */
> > > > + for (;;) {
> > > > + /*
> > > > + * c-cas to avoid the exclusive bouncing on spin.
> > > > + * Depends on the memory barrier implied by cmpxchg
> > > > + * for ACQUIRE semantics.
> > > > + */
> > > > + old = READ_ONCE(early_printk_cpu);
> > > > + if (old == -1) {
> > >
> > > If old != -1 and old != cpu, is it possible that the CPU could have
> > > fetched an old value, and never try to fetch it again?
> >
> > What? If old != -1 and old != cpu, we'll hit the cpu_relax() and do the
> > READ_ONCE() again. The READ_ONCE() guarantees we'll do the load again,
> > as does the barrier() implied by cpu_relax().
>
> I'm more worried about other architectures that don't have as strong of
> a cache coherency.
>
> [ Added Paul as he knows a lot about odd architectures ]
>
> Is there any architecture that we support that can have the following:
>
> CPU0 CPU1
> ---- ----
> early_printk_cpu = 1
> for (;;)
> old = READ_ONCE(early_printk_cpu);
> [ old = 1 ]
>
> early_printk_cpu = -1
>
> [...]
> cpu_relax();
> old = READ_ONCE(early_printk_cpu);
>
> [ but the CPU uses the cache and not the memory? ]
>
> old = 1;
If you use READ_ONCE(), then all architectures I know of enforce
full ordering for accesses to a single variable. (If you don't use
READ_ONCE(), then in theory Itanium can reorder reads.) Me, I would
argue for WRITE_ONCE() as well to prevent store tearing.
It is only when you have at least two variables and at least two threads
than things start getting really "interesting". ;-)
Thanx, Paul
> -- Steve
>
>
> >
> > > The cmpxchg memory barrier only happens when old == -1.
> >
> > Yeah, so?
> >
> > > > + old = cmpxchg(&early_printk_cpu, -1, cpu);
> > > > + if (old == -1)
> > > > + break;
> > > > + }
> > > > + /*
> > > > + * Allow recursion for interrupts and the like.
> > > > + */
> > > > + if (old == cpu)
> > > > + break;
> > > > +
> > > > + cpu_relax();
> > > > + }
> > > >
> > > > n = vscnprintf(buf, sizeof(buf), fmt, args);
> > > > early_console->write(early_console, buf, n);
> > > >
> > > > + /*
> > > > + * Unlock -- in case @old == @cpu, this is a no-op.
> > > > + */
> > > > + smp_store_release(&early_printk_cpu, old);
> > > > + put_cpu();
> > > > +
> > > > return n;
> > > > }
>
next prev parent reply other threads:[~2017-10-04 14:17 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 12:18 [PATCH 0/3] printk: Add force_early_printk boot param Peter Zijlstra
2017-09-28 12:18 ` [PATCH 1/3] printk: Fix kdb_trap_printk placement Peter Zijlstra
2017-10-03 22:10 ` Steven Rostedt
2017-10-05 13:38 ` Petr Mladek
2017-10-05 13:42 ` Peter Zijlstra
2017-10-09 15:05 ` Petr Mladek
2017-10-12 9:45 ` Petr Mladek
2017-10-12 10:03 ` Petr Mladek
2017-10-12 11:34 ` Peter Zijlstra
2017-10-12 11:52 ` Greg Kroah-Hartman
2017-10-12 12:08 ` Greg Kroah-Hartman
2017-10-12 18:11 ` Joe Perches
2017-10-13 14:23 ` Petr Mladek
2017-10-12 11:30 ` Peter Zijlstra
2017-09-28 12:18 ` [PATCH 2/3] early_printk: Add force_early_printk kernel parameter Peter Zijlstra
2017-09-28 15:41 ` Randy Dunlap
2017-09-28 16:07 ` Peter Zijlstra
2017-09-28 17:05 ` Randy Dunlap
2017-10-03 22:18 ` Steven Rostedt
2017-10-12 10:24 ` Petr Mladek
2017-10-12 11:39 ` Peter Zijlstra
2017-10-13 13:06 ` Petr Mladek
2017-10-13 13:20 ` Peter Zijlstra
2017-10-13 13:30 ` Steven Rostedt
2017-09-28 12:18 ` [PATCH 3/3] early_printk: Add simple serialization to early_vprintk() Peter Zijlstra
2017-10-03 22:24 ` Steven Rostedt
2017-10-04 9:08 ` Peter Zijlstra
2017-10-04 13:04 ` Steven Rostedt
2017-10-04 13:08 ` Peter Zijlstra
2017-10-04 14:17 ` Paul E. McKenney [this message]
2017-10-04 14:43 ` Steven Rostedt
2017-10-04 14:52 ` Peter Zijlstra
2017-10-04 15:02 ` Steven Rostedt
2017-10-04 15:14 ` Paul E. McKenney
2017-10-04 15:24 ` Peter Zijlstra
2017-10-04 15:38 ` Paul E. McKenney
2017-09-28 16:02 ` [PATCH 0/3] printk: Add force_early_printk boot param Sergey Senozhatsky
2017-09-28 16:17 ` Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2016-10-18 17:08 [PATCH 0/3] make printk work again Peter Zijlstra
2016-10-18 17:08 ` [PATCH 3/3] early_printk: Add simple serialization to early_vprintk() Peter Zijlstra
2016-10-18 17:19 ` Steven Rostedt
2016-10-18 17:30 ` Peter Zijlstra
2016-10-18 17:53 ` Steven Rostedt
2016-11-29 14:10 ` Petr Mladek
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=20171004141745.GH3521@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/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