From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Andrea Parri <parri.andrea@gmail.com>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Brendan Higgins <brendanhiggins@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: dataring_push() barriers Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation
Date: Wed, 28 Aug 2019 15:43:50 +0200 [thread overview]
Message-ID: <87pnkpjtgp.fsf@linutronix.de> (raw)
In-Reply-To: <20190827143635.4taqjj6wjz7gdlea@pathway.suse.cz> (Petr Mladek's message of "Tue, 27 Aug 2019 16:36:35 +0200")
On 2019-08-27, Petr Mladek <pmladek@suse.com> wrote:
>>>> +/**
>>>> + * dataring_push() - Reserve a data block in the data array.
>>>> + *
>>>> + * @dr: The data ringbuffer to reserve data in.
>>>> + *
>>>> + * @size: The size to reserve.
>>>> + *
>>>> + * @desc: A pointer to a descriptor to store the data block information.
>>>> + *
>>>> + * @id: The ID of the descriptor to be associated.
>>>> + * The data block will not be set with @id, but rather initialized with
>>>> + * a value that is explicitly different than @id. This is to handle the
>>>> + * case when newly available garbage by chance matches the descriptor
>>>> + * ID.
>>>> + *
>>>> + * This function expects to move the head pointer forward. If this would
>>>> + * result in overtaking the data array index of the tail, the tail data block
>>>> + * will be invalidated.
>>>> + *
>>>> + * Return: A pointer to the reserved writer data, otherwise NULL.
>>>> + *
>>>> + * This will only fail if it was not possible to invalidate the tail data
>>>> + * block.
>>>> + */
>>>> +char *dataring_push(struct dataring *dr, unsigned int size,
>>>> + struct dr_desc *desc, unsigned long id)
>>>> +{
>>>> + unsigned long begin_lpos;
>>>> + unsigned long next_lpos;
>>>> + struct dr_datablock *db;
>>>> + bool ret;
>>>> +
>>>> + to_db_size(&size);
>>>> +
>>>> + do {
>>>> + /* fA: */
>>>> + ret = get_new_lpos(dr, size, &begin_lpos, &next_lpos);
>>>> +
>>>> + /*
>>>> + * fB:
>>>> + *
>>>> + * The data ringbuffer tail may have been pushed (by this or
>>>> + * any other task). The updated @tail_lpos must be visible to
>>>> + * all observers before changes to @begin_lpos, @next_lpos, or
>>>> + * @head_lpos by this task are visible in order to allow other
>>>> + * tasks to recognize the invalidation of the data
>>>> + * blocks.
>>>
>>> This sounds strange. The write barrier should be done only on CPU
>>> that really modified tail_lpos. I.e. it should be in _dataring_pop()
>>> after successful dr->tail_lpos modification.
>>
>> The problem is that there are no data dependencies between the different
>> variables. When a new datablock is being reserved, it is critical that
>> all other observers see that the tail_lpos moved forward _before_ any
>> other changes. _dataring_pop() uses an smp_rmb() to synchronize for
>> tail_lpos movement.
>
> It should be symmetric. It makes sense that _dataring_pop() uses an
> smp_rmb(). Then there should be wmb() in dataring_push().
dataring_pop() is adjusting the tail. dataring_push() is adjusting the
head. These operations are handled (ordered) separately. They do not
need be happening in lockstep. They don't need to be happening on the
same CPU.
> The wmb() should be done only by the CPU that actually did the write.
> And it should be done after the write. This is why I suggested to
> do it after cmpxchg(dr->head_lpos).
If CPU0 issues an smp_wmb() after moving the tail and (after seeing the
moved tail) CPU1 issues an smp_wmb() after updating the head, it is
still possible for CPU2 to see the head move (and possibly even overtake
the tail) before seeing the tail move.
If a CPU didn't move the tail but _will_ move the head, only a full
memory barrier will allow _all_ observers to see the tail move before
seeing the head move.
>> This CPU is about to make some changes and may have seen an updated
>> tail_lpos. An smp_wmb() is useless if this is not the CPU that
>> performed that update. The full memory barrier ensures that all other
>> observers will see what this CPU sees before any of its future
>> changes are seen.
>
> I do not understand it. Full memory barrier will not cause that all
> CPUs will see the same.
I did not write that. I wrote (emphasis added):
The full memory barrier ensures that all other observers will see
what _this_ CPU sees before any of _its_ future changes are seen.
> These barriers need to be symmetric.
They are. The comments for fB list the pairs (all being
smp_mb()/smp_rmb() pairings).
> Back to our situation:
>
> + rmb() should not be needed here because get_new_lpos() provided
> a valid lpos.
>
> + wmb() is not needed because we have not written anything yet
>
> If there was a race with another CPU than cmpxchg(dr->head_lpos)
> would fail and we will need to repeat everything again.
It's not about racing to update the head. It's about making sure that
_all_ CPUs observe that a datablock was invalidated _before_ observing
that _this_ CPU started modifying other shared variables. And again,
this CPU might _not_ be the one that invalidated the datablock
(i.e. moved the tail).
John Ogness
next prev parent reply other threads:[~2019-08-28 13:45 UTC|newest]
Thread overview: 131+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 22:26 [RFC PATCH v4 0/9] printk: new ringbuffer implementation John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 1/9] printk-rb: add a new printk " John Ogness
2019-08-20 8:15 ` numlist_pop(): " Petr Mladek
2019-08-21 5:41 ` John Ogness
2019-09-04 12:19 ` Peter Zijlstra
2019-08-20 8:22 ` assign_desc() barriers: " Petr Mladek
2019-08-20 14:14 ` Petr Mladek
2019-08-21 5:52 ` John Ogness
2019-08-22 11:53 ` Petr Mladek
2019-08-25 2:06 ` John Ogness
2019-08-26 8:21 ` John Ogness
2019-08-20 8:55 ` comments style: " Petr Mladek
2019-08-20 9:27 ` Sergey Senozhatsky
2019-08-21 5:46 ` John Ogness
2019-08-22 13:50 ` Petr Mladek
2019-08-22 17:38 ` Andrea Parri
2019-08-23 10:47 ` Petr Mladek
2019-08-23 14:27 ` Andrea Parri
2019-08-23 9:49 ` Sergey Senozhatsky
2019-08-23 5:54 ` Sergey Senozhatsky
2019-08-23 10:29 ` Petr Mladek
2019-08-21 5:42 ` John Ogness
2019-08-22 12:44 ` Petr Mladek
2019-08-20 13:50 ` dataring_push() barriers " Petr Mladek
2019-08-25 2:42 ` John Ogness
2019-08-27 14:36 ` Petr Mladek
2019-08-28 13:43 ` John Ogness [this message]
2019-08-20 15:12 ` datablock reuse races " Petr Mladek
2019-08-23 9:21 ` numlist_push() barriers " Petr Mladek
2019-08-26 8:34 ` Andrea Parri
2019-08-26 8:43 ` Andrea Parri
2019-08-26 14:10 ` Petr Mladek
2019-08-26 16:01 ` Andrea Parri
2019-08-26 22:36 ` John Ogness
2019-08-27 7:40 ` Petr Mladek
2019-08-27 14:28 ` John Ogness
2019-08-27 15:07 ` Petr Mladek
2019-08-28 10:24 ` John Ogness
2019-08-23 17:18 ` numlist API " Petr Mladek
2019-08-26 23:57 ` John Ogness
2019-08-27 13:03 ` Petr Mladek
2019-08-28 7:13 ` John Ogness
2019-08-28 8:58 ` Petr Mladek
2019-08-28 14:03 ` John Ogness
2019-08-29 11:28 ` Petr Mladek
2019-09-03 7:58 ` Sergey Senozhatsky
2019-08-30 14:48 ` dataring " Petr Mladek
2019-08-07 22:26 ` [RFC PATCH v4 2/9] printk-rb: add test module John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 3/9] printk-rb: fix missing includes/exports John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 4/9] printk-rb: initialize new descriptors as invalid John Ogness
2019-08-20 9:23 ` Petr Mladek
2019-08-20 10:16 ` Sergey Senozhatsky
2019-08-21 5:56 ` John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 5/9] printk-rb: remove extra data buffer size allocation John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 6/9] printk-rb: adjust test module ringbuffer sizes John Ogness
2019-08-19 21:29 ` [PATCH] printk-rb: fix test module macro usage John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 7/9] printk-rb: increase size of seq and size variables John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 8/9] printk-rb: new functionality to support printk John Ogness
2019-08-20 9:59 ` Sergey Senozhatsky
2019-08-21 5:47 ` John Ogness
2019-08-07 22:26 ` [RFC PATCH v4 9/9] printk: use a new ringbuffer implementation John Ogness
2019-08-08 19:07 ` Linus Torvalds
2019-08-08 22:55 ` John Ogness
2019-08-08 23:33 ` Linus Torvalds
2019-08-08 23:45 ` Steven Rostedt
2019-08-09 0:21 ` Linus Torvalds
2019-08-09 0:48 ` Steven Rostedt
2019-08-09 1:15 ` Linus Torvalds
2019-08-09 11:15 ` Thomas Gleixner
2019-08-09 16:00 ` Linus Torvalds
2019-08-09 20:07 ` Thomas Gleixner
2019-08-09 20:20 ` Linus Torvalds
2019-08-09 6:14 ` Peter Zijlstra
2019-08-09 7:08 ` John Ogness
2019-08-09 15:57 ` Linus Torvalds
2019-08-10 5:53 ` Thomas Gleixner
2019-09-10 3:19 ` Sergey Senozhatsky
2019-08-12 9:54 ` Geert Uytterhoeven
2019-08-16 5:46 ` Dave Young
2019-08-16 5:54 ` Dave Young
2019-08-16 9:40 ` John Ogness
2019-09-04 12:35 ` [RFC PATCH v4 0/9] printk: " Peter Zijlstra
2019-09-05 13:05 ` Petr Mladek
2019-09-05 14:31 ` Peter Zijlstra
2019-09-05 15:38 ` Thomas Gleixner
2019-09-05 16:11 ` Steven Rostedt
2019-09-05 21:10 ` John Ogness
2019-09-06 9:39 ` Petr Mladek
2019-09-09 14:11 ` printk meeting at LPC Thomas Gleixner
2019-09-13 13:26 ` John Ogness
2019-09-13 14:48 ` Daniel Vetter
2019-09-15 13:47 ` John Ogness
2019-09-16 8:44 ` Daniel Vetter
2019-09-16 4:30 ` Tetsuo Handa
2019-09-16 10:46 ` Petr Mladek
2019-09-16 13:43 ` Steven Rostedt
2019-09-16 14:28 ` John Ogness
2019-09-17 8:11 ` Petr Mladek
2019-09-17 7:52 ` Petr Mladek
2019-09-17 13:02 ` Steven Rostedt
2019-09-17 13:12 ` Greg Kroah-Hartman
2019-09-17 13:37 ` Steven Rostedt
2019-09-17 14:08 ` Tetsuo Handa
2019-09-17 7:51 ` Sergey Senozhatsky
2019-09-18 1:25 ` Sergey Senozhatsky
2019-09-18 2:08 ` Steven Rostedt
2019-09-18 2:36 ` Sergey Senozhatsky
2019-09-18 5:19 ` Sergey Senozhatsky
2019-09-18 7:42 ` John Ogness
2019-09-18 8:10 ` Sergey Senozhatsky
2019-09-18 9:05 ` John Ogness
2019-09-18 9:11 ` Sergey Senozhatsky
2019-09-18 16:41 ` Petr Mladek
2019-09-18 16:48 ` Steven Rostedt
2019-09-24 14:24 ` Petr Mladek
2019-09-19 8:06 ` Daniel Vetter
2019-09-18 7:33 ` John Ogness
2019-09-18 8:08 ` Sergey Senozhatsky
2019-10-04 14:48 ` Tony Asleson
2019-10-07 12:01 ` Petr Mladek
2019-09-06 9:06 ` [RFC PATCH v4 0/9] printk: new ringbuffer implementation Peter Zijlstra
2019-09-06 10:09 ` Sergey Senozhatsky
2019-09-06 10:49 ` Peter Zijlstra
2019-09-06 13:44 ` Sergey Senozhatsky
2019-09-06 12:42 ` Petr Mladek
2019-09-06 14:01 ` Peter Zijlstra
2019-09-06 14:22 ` Peter Zijlstra
2019-09-06 19:53 ` Sergey Senozhatsky
2019-09-06 22:47 ` John Ogness
2019-09-08 22:18 ` Peter Zijlstra
2019-09-10 3:22 ` Sergey Senozhatsky
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=87pnkpjtgp.fsf@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=andrea.parri@amarulasolutions.com \
--cc=brendanhiggins@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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).