[PATCH 0/3] toyrcu: Misc. fixes

[PATCH 0/3] toyrcu: Misc. fixes

[Akira Yokosawa]

From 2d0d9c606bf94a9c993f84fb8b5087de6c00b212 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Tue, 20 Jun 2017 23:17:56 +0900
Subject: [PATCH 0/3] toyrcu: Misc. fixes

Hi Paul,

While I was preparing patches related to unit symbol usage, I noticed
a few issues in toyrcu section.

Patch 1 is trivial.
Patch 2 seems also trivial, as long as my understanding is correct.
Patch 3 is a follow-up patch to the previous patch set.

                  Thanks, Akira
-- 
Akira Yokosawa (3):
  toyrcu: Adjust reference to prerequisite chapters
  toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
  future/QC: Another math mode fix

 appendix/toyrcu/toyrcu.tex | 17 ++++++++---------
 future/QC.tex              |  2 +-
 2 files changed, 9 insertions(+), 10 deletions(-)

-- 
2.7.4

[PATCH 1/3] toyrcu: Adjust reference to prerequisite chapters

[Akira Yokosawa]

From ac7a508e515ec6aba4f0f45405b50440304864c6 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 17 Jun 2017 17:11:53 +0900
Subject: [PATCH 1/3] toyrcu: Adjust reference to prerequisite chapters

This reverts the 1st hunk of commit afff91238e3d ("Fix Toy RCU
section references") with an nbsp change.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 appendix/toyrcu/toyrcu.tex | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
index 5e74afa..79fbe33 100644
--- a/appendix/toyrcu/toyrcu.tex
+++ b/appendix/toyrcu/toyrcu.tex
@@ -10,10 +10,9 @@ but rather for clarity.
 Nevertheless, you will need a thorough understanding of
 Chapters~\ref{chp:Introduction},
 \ref{chp:Hardware and its Habits},
-\ref{chp:Tools of the Trade}, and
+\ref{chp:Tools of the Trade},
 \ref{cha:Partitioning and Synchronization Design},
-as well as the previous portions of
-Chapter~\ref{chp:Deferred Processing}
+and~\ref{chp:Deferred Processing}
 for even these toy RCU implementations to be easily understandable.

 This section provides a series of RCU implementations in order of
-- 
2.7.4

[PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)

[Akira Yokosawa]

From db0fd6b383b551eabecb12dfa21e42093f338b2f Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Mon, 19 Jun 2017 23:55:31 +0900
Subject: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 appendix/toyrcu/toyrcu.tex | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
index 79fbe33..a7bf6ca 100644
--- a/appendix/toyrcu/toyrcu.tex
+++ b/appendix/toyrcu/toyrcu.tex
@@ -524,10 +524,10 @@ by complementing the value of \co{rcu_idx}, as in \co{rcu_idx = !rcu_idx}.
 Suppose that the old value of \co{rcu_idx} was zero, so that the new
 value is one.
 New readers that arrive after the complement operation will increment
-\co{rcu_idx[1]}, while the old readers that previously incremented
-\co{rcu_idx[0]} will decrement \co{rcu_idx[0]} when they exit their
+\co{rcu_refcnt[1]}, while the old readers that previously incremented
+\co{rcu_refcnt[0]} will decrement \co{rcu_refcnt[0]} when they exit their
 RCU read-side critical sections.
-This means that the value of \co{rcu_idx[0]} will no longer be incremented,
+This means that the value of \co{rcu_refcnt[0]} will no longer be incremented,
 and thus will be monotonically decreasing.\footnote{
 	There is a race condition that this ``monotonically decreasing''
 	statement ignores.
@@ -616,11 +616,11 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
 prevent more than one concurrent instance of \co{synchronize_rcu()}.
 Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
 respectively, so that subsequent instances of \co{rcu_read_lock()}
-will use a different element of \co{rcu_idx} that did preceding
+will use a different element of \co{rcu_refcnt} that did preceding
 instances.
-Lines~10-12 then wait for the prior element of \co{rcu_idx} to
+Lines~10-12 then wait for the prior element of \co{rcu_refcnt} to
 reach zero, with the memory barrier on line~9 ensuring that the check
-of \co{rcu_idx} is not reordered to precede the complementing of
+of \co{rcu_refcnt} is not reordered to precede the complementing of
 \co{rcu_idx}.
 Lines~13-18 repeat this process, and line~20 ensures that any
 subsequent reclamation operations are not reordered to precede the
-- 
2.7.4

Re: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)

[Akira Yokosawa]

On 2017/06/20 23:28, Akira Yokosawa wrote:
>>From db0fd6b383b551eabecb12dfa21e42093f338b2f Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <akiyks@gmail.com>
> Date: Mon, 19 Jun 2017 23:55:31 +0900
> Subject: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
> 
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
>  appendix/toyrcu/toyrcu.tex | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
> index 79fbe33..a7bf6ca 100644
> --- a/appendix/toyrcu/toyrcu.tex
> +++ b/appendix/toyrcu/toyrcu.tex
> @@ -524,10 +524,10 @@ by complementing the value of \co{rcu_idx}, as in \co{rcu_idx = !rcu_idx}.
>  Suppose that the old value of \co{rcu_idx} was zero, so that the new
>  value is one.
>  New readers that arrive after the complement operation will increment
> -\co{rcu_idx[1]}, while the old readers that previously incremented
> -\co{rcu_idx[0]} will decrement \co{rcu_idx[0]} when they exit their
> +\co{rcu_refcnt[1]}, while the old readers that previously incremented
> +\co{rcu_refcnt[0]} will decrement \co{rcu_refcnt[0]} when they exit their
>  RCU read-side critical sections.
> -This means that the value of \co{rcu_idx[0]} will no longer be incremented,
> +This means that the value of \co{rcu_refcnt[0]} will no longer be incremented,
>  and thus will be monotonically decreasing.\footnote{
>  	There is a race condition that this ``monotonically decreasing''
>  	statement ignores.
> @@ -616,11 +616,11 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
>  prevent more than one concurrent instance of \co{synchronize_rcu()}.
>  Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
>  respectively, so that subsequent instances of \co{rcu_read_lock()}
> -will use a different element of \co{rcu_idx} that did preceding
> +will use a different element of \co{rcu_refcnt} that did preceding
>  instances.

I have a little trouble with this sentence. Do you mean:

             ..., so that subsequent instances of \co{rcu_read_lock()}
will use a different element of \co{rcu_refcnt} from the one did preceding
instances.                                      

???

       Thanks, Akira
> -Lines~10-12 then wait for the prior element of \co{rcu_idx} to
> +Lines~10-12 then wait for the prior element of \co{rcu_refcnt} to
>  reach zero, with the memory barrier on line~9 ensuring that the check
> -of \co{rcu_idx} is not reordered to precede the complementing of
> +of \co{rcu_refcnt} is not reordered to precede the complementing of
>  \co{rcu_idx}.
>  Lines~13-18 repeat this process, and line~20 ensures that any
>  subsequent reclamation operations are not reordered to precede the
> 

Re: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)

[Paul E. McKenney]

On Wed, Jun 21, 2017 at 07:55:34AM +0900, Akira Yokosawa wrote:
> On 2017/06/20 23:28, Akira Yokosawa wrote:
> >>From db0fd6b383b551eabecb12dfa21e42093f338b2f Mon Sep 17 00:00:00 2001
> > From: Akira Yokosawa <akiyks@gmail.com>
> > Date: Mon, 19 Jun 2017 23:55:31 +0900
> > Subject: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
> > 
> > Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> > ---
> >  appendix/toyrcu/toyrcu.tex | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
> > index 79fbe33..a7bf6ca 100644
> > --- a/appendix/toyrcu/toyrcu.tex
> > +++ b/appendix/toyrcu/toyrcu.tex
> > @@ -524,10 +524,10 @@ by complementing the value of \co{rcu_idx}, as in \co{rcu_idx = !rcu_idx}.
> >  Suppose that the old value of \co{rcu_idx} was zero, so that the new
> >  value is one.
> >  New readers that arrive after the complement operation will increment
> > -\co{rcu_idx[1]}, while the old readers that previously incremented
> > -\co{rcu_idx[0]} will decrement \co{rcu_idx[0]} when they exit their
> > +\co{rcu_refcnt[1]}, while the old readers that previously incremented
> > +\co{rcu_refcnt[0]} will decrement \co{rcu_refcnt[0]} when they exit their
> >  RCU read-side critical sections.
> > -This means that the value of \co{rcu_idx[0]} will no longer be incremented,
> > +This means that the value of \co{rcu_refcnt[0]} will no longer be incremented,
> >  and thus will be monotonically decreasing.\footnote{
> >  	There is a race condition that this ``monotonically decreasing''
> >  	statement ignores.
> > @@ -616,11 +616,11 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
> >  prevent more than one concurrent instance of \co{synchronize_rcu()}.
> >  Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
> >  respectively, so that subsequent instances of \co{rcu_read_lock()}
> > -will use a different element of \co{rcu_idx} that did preceding
> > +will use a different element of \co{rcu_refcnt} that did preceding
> >  instances.
> 
> I have a little trouble with this sentence. Do you mean:
> 
>              ..., so that subsequent instances of \co{rcu_read_lock()}
> will use a different element of \co{rcu_refcnt} from the one did preceding
> instances.                                      

Just to fully illustrate:

1.	Suppose that rcu_idx is initially zero.

2.	Any rcu_read_lock() invocations running at this point will
	therefore be incrementing rcu_refcnt[0].

3.	A synchronize_srcu() instance now complements rcu_idx, so that
	its new value is one.

4.	Any rcu_read_lock() invocations from step 2 that fetched rcu_idx
	before step 3 completed will still increment rcu_refcnt[0].

5.	However, any subsequent rcu_read_lock() invocations will instead
	increment rcu_refcnt[1].  (At least until the next invocation
	of synchronize_rcu().)

Does that help, or am I missing the point of your question?

							Thanx, Paul

> ???
> 
>        Thanks, Akira
> > -Lines~10-12 then wait for the prior element of \co{rcu_idx} to
> > +Lines~10-12 then wait for the prior element of \co{rcu_refcnt} to
> >  reach zero, with the memory barrier on line~9 ensuring that the check
> > -of \co{rcu_idx} is not reordered to precede the complementing of
> > +of \co{rcu_refcnt} is not reordered to precede the complementing of
> >  \co{rcu_idx}.
> >  Lines~13-18 repeat this process, and line~20 ensures that any
> >  subsequent reclamation operations are not reordered to precede the
> > 
> 

Re: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)

[Akira Yokosawa]

On 2017/06/21 10:45:41 -0700, Paul E. McKenney wrote:
> On Wed, Jun 21, 2017 at 07:55:34AM +0900, Akira Yokosawa wrote:
>> On 2017/06/20 23:28, Akira Yokosawa wrote:
>>> >From db0fd6b383b551eabecb12dfa21e42093f338b2f Mon Sep 17 00:00:00 2001
>>> From: Akira Yokosawa <akiyks@gmail.com>
>>> Date: Mon, 19 Jun 2017 23:55:31 +0900
>>> Subject: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
>>>
>>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
>>> ---
>>>  appendix/toyrcu/toyrcu.tex | 12 ++++++------
>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
>>> index 79fbe33..a7bf6ca 100644
>>> --- a/appendix/toyrcu/toyrcu.tex
>>> +++ b/appendix/toyrcu/toyrcu.tex
>>> @@ -524,10 +524,10 @@ by complementing the value of \co{rcu_idx}, as in \co{rcu_idx = !rcu_idx}.
>>>  Suppose that the old value of \co{rcu_idx} was zero, so that the new
>>>  value is one.
>>>  New readers that arrive after the complement operation will increment
>>> -\co{rcu_idx[1]}, while the old readers that previously incremented
>>> -\co{rcu_idx[0]} will decrement \co{rcu_idx[0]} when they exit their
>>> +\co{rcu_refcnt[1]}, while the old readers that previously incremented
>>> +\co{rcu_refcnt[0]} will decrement \co{rcu_refcnt[0]} when they exit their
>>>  RCU read-side critical sections.
>>> -This means that the value of \co{rcu_idx[0]} will no longer be incremented,
>>> +This means that the value of \co{rcu_refcnt[0]} will no longer be incremented,
>>>  and thus will be monotonically decreasing.\footnote{
>>>  	There is a race condition that this ``monotonically decreasing''
>>>  	statement ignores.
>>> @@ -616,11 +616,11 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
>>>  prevent more than one concurrent instance of \co{synchronize_rcu()}.
>>>  Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
>>>  respectively, so that subsequent instances of \co{rcu_read_lock()}
>>> -will use a different element of \co{rcu_idx} that did preceding
>>> +will use a different element of \co{rcu_refcnt} that did preceding
>>>  instances.
>>
>> I have a little trouble with this sentence. Do you mean:
>>
>>              ..., so that subsequent instances of \co{rcu_read_lock()}
>> will use a different element of \co{rcu_refcnt} from the one did preceding
>> instances.                                      
> 
> Just to fully illustrate:
> 
> 1.	Suppose that rcu_idx is initially zero.
> 
> 2.	Any rcu_read_lock() invocations running at this point will
> 	therefore be incrementing rcu_refcnt[0].
> 
> 3.	A synchronize_srcu() instance now complements rcu_idx, so that
> 	its new value is one.
> 
> 4.	Any rcu_read_lock() invocations from step 2 that fetched rcu_idx
> 	before step 3 completed will still increment rcu_refcnt[0].
> 
> 5.	However, any subsequent rcu_read_lock() invocations will instead
> 	increment rcu_refcnt[1].  (At least until the next invocation
> 	of synchronize_rcu().)
> 
> Does that help, or am I missing the point of your question?

Thanks. This is what I guessed you mean.

So what bothered me was the structure of the clause. I rarely see a sentence like:

    I will buy a different model of PC that did you.

I can't figure out the grammatical role of "that" here.

           Thanks, Akira

> 
> 							Thanx, Paul
> 
>> ???
>>
>>        Thanks, Akira
>>> -Lines~10-12 then wait for the prior element of \co{rcu_idx} to
>>> +Lines~10-12 then wait for the prior element of \co{rcu_refcnt} to
>>>  reach zero, with the memory barrier on line~9 ensuring that the check
>>> -of \co{rcu_idx} is not reordered to precede the complementing of
>>> +of \co{rcu_refcnt} is not reordered to precede the complementing of
>>>  \co{rcu_idx}.
>>>  Lines~13-18 repeat this process, and line~20 ensures that any
>>>  subsequent reclamation operations are not reordered to precede the
>>>
>>
> 
> 

Re: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)

[Paul E. McKenney]

On Thu, Jun 22, 2017 at 07:46:57AM +0900, Akira Yokosawa wrote:
> On 2017/06/21 10:45:41 -0700, Paul E. McKenney wrote:
> > On Wed, Jun 21, 2017 at 07:55:34AM +0900, Akira Yokosawa wrote:
> >> On 2017/06/20 23:28, Akira Yokosawa wrote:
> >>> >From db0fd6b383b551eabecb12dfa21e42093f338b2f Mon Sep 17 00:00:00 2001
> >>> From: Akira Yokosawa <akiyks@gmail.com>
> >>> Date: Mon, 19 Jun 2017 23:55:31 +0900
> >>> Subject: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
> >>>
> >>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> >>> ---
> >>>  appendix/toyrcu/toyrcu.tex | 12 ++++++------
> >>>  1 file changed, 6 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
> >>> index 79fbe33..a7bf6ca 100644
> >>> --- a/appendix/toyrcu/toyrcu.tex
> >>> +++ b/appendix/toyrcu/toyrcu.tex
> >>> @@ -524,10 +524,10 @@ by complementing the value of \co{rcu_idx}, as in \co{rcu_idx = !rcu_idx}.
> >>>  Suppose that the old value of \co{rcu_idx} was zero, so that the new
> >>>  value is one.
> >>>  New readers that arrive after the complement operation will increment
> >>> -\co{rcu_idx[1]}, while the old readers that previously incremented
> >>> -\co{rcu_idx[0]} will decrement \co{rcu_idx[0]} when they exit their
> >>> +\co{rcu_refcnt[1]}, while the old readers that previously incremented
> >>> +\co{rcu_refcnt[0]} will decrement \co{rcu_refcnt[0]} when they exit their
> >>>  RCU read-side critical sections.
> >>> -This means that the value of \co{rcu_idx[0]} will no longer be incremented,
> >>> +This means that the value of \co{rcu_refcnt[0]} will no longer be incremented,
> >>>  and thus will be monotonically decreasing.\footnote{
> >>>  	There is a race condition that this ``monotonically decreasing''
> >>>  	statement ignores.
> >>> @@ -616,11 +616,11 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
> >>>  prevent more than one concurrent instance of \co{synchronize_rcu()}.
> >>>  Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
> >>>  respectively, so that subsequent instances of \co{rcu_read_lock()}
> >>> -will use a different element of \co{rcu_idx} that did preceding
> >>> +will use a different element of \co{rcu_refcnt} that did preceding
> >>>  instances.
> >>
> >> I have a little trouble with this sentence. Do you mean:
> >>
> >>              ..., so that subsequent instances of \co{rcu_read_lock()}
> >> will use a different element of \co{rcu_refcnt} from the one did preceding
> >> instances.                                      
> > 
> > Just to fully illustrate:
> > 
> > 1.	Suppose that rcu_idx is initially zero.
> > 
> > 2.	Any rcu_read_lock() invocations running at this point will
> > 	therefore be incrementing rcu_refcnt[0].
> > 
> > 3.	A synchronize_srcu() instance now complements rcu_idx, so that
> > 	its new value is one.
> > 
> > 4.	Any rcu_read_lock() invocations from step 2 that fetched rcu_idx
> > 	before step 3 completed will still increment rcu_refcnt[0].
> > 
> > 5.	However, any subsequent rcu_read_lock() invocations will instead
> > 	increment rcu_refcnt[1].  (At least until the next invocation
> > 	of synchronize_rcu().)
> > 
> > Does that help, or am I missing the point of your question?
> 
> Thanks. This is what I guessed you mean.
> 
> So what bothered me was the structure of the clause. I rarely see a sentence like:
> 
>     I will buy a different model of PC that did you.
> 
> I can't figure out the grammatical role of "that" here.

Color me blind!!!  The "that" should be "than".  My brain autocorrected on
first reading, so I couldn't even see it.  I queued the following patch.

							Thanx, Paul

------------------------------------------------------------------------

commit ed403934aeff63a46db4412d6a485f42d39daabd
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Wed Jun 21 16:03:43 2017 -0700

    toyrcu: Typo s/that/than/
    
    Reported-by: Akira Yokosawa <akiyks@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
index a7bf6ca25616..3f19662aa1c2 100644
--- a/appendix/toyrcu/toyrcu.tex
+++ b/appendix/toyrcu/toyrcu.tex
@@ -616,7 +616,7 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
 prevent more than one concurrent instance of \co{synchronize_rcu()}.
 Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
 respectively, so that subsequent instances of \co{rcu_read_lock()}
-will use a different element of \co{rcu_refcnt} that did preceding
+will use a different element of \co{rcu_refcnt} than did preceding
 instances.
 Lines~10-12 then wait for the prior element of \co{rcu_refcnt} to
 reach zero, with the memory barrier on line~9 ensuring that the check

[PATCH 3/3] future/QC: Another math mode fix

[Akira Yokosawa]

From 2d0d9c606bf94a9c993f84fb8b5087de6c00b212 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Tue, 20 Jun 2017 23:12:40 +0900
Subject: [PATCH 3/3] future/QC: Another math mode fix

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 future/QC.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/future/QC.tex b/future/QC.tex
index bd85217..d16c080 100644
--- a/future/QC.tex
+++ b/future/QC.tex
@@ -993,7 +993,7 @@ too early to start thinking in terms of replacing RSA.
 \paragraph{Grover's Search Algorithm}
 \label{sec:future:Grover's Search Algorithm}

-Grover's algorithm searches an unordered list of N items
+Grover's algorithm searches an unordered list of $N$ items
 in $O(\sqrt N)$ time.
 But before this can happen, the list must be downloaded into
 the QC system.
-- 
2.7.4

Re: [PATCH 0/3] toyrcu: Misc. fixes

[Paul E. McKenney]

On Tue, Jun 20, 2017 at 11:26:30PM +0900, Akira Yokosawa wrote:
> >From 2d0d9c606bf94a9c993f84fb8b5087de6c00b212 Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <akiyks@gmail.com>
> Date: Tue, 20 Jun 2017 23:17:56 +0900
> Subject: [PATCH 0/3] toyrcu: Misc. fixes
> 
> Hi Paul,
> 
> While I was preparing patches related to unit symbol usage, I noticed
> a few issues in toyrcu section.
> 
> Patch 1 is trivial.
> Patch 2 seems also trivial, as long as my understanding is correct.
> Patch 3 is a follow-up patch to the previous patch set.

Queued and pushed, good catches, thank you!

							Thanx, Paul

>                   Thanks, Akira
> -- 
> Akira Yokosawa (3):
>   toyrcu: Adjust reference to prerequisite chapters
>   toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
>   future/QC: Another math mode fix
> 
>  appendix/toyrcu/toyrcu.tex | 17 ++++++++---------
>  future/QC.tex              |  2 +-
>  2 files changed, 9 insertions(+), 10 deletions(-)
> 
> -- 
> 2.7.4
> 
>