| Message ID | Pine.LNX.4.64.0903302210030.13385@ask.diku.dk |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, Mar 30, 2009 at 10:11:47PM +0200, Jesper Dangaard Brouer wrote: > > Trival spelling fixes in RCU/rculist_nulls.txt. > > Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Jarek Poplawski <jarkao2@gmail.com> Hmm... still "reviewing", and maybe it's only me, but can't apply... (v1 works OK.) Jarek P. > Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> > --- > > Documentation/RCU/rculist_nulls.txt | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > > diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt > index 239f542..6389dec 100644 > --- a/Documentation/RCU/rculist_nulls.txt > +++ b/Documentation/RCU/rculist_nulls.txt > @@ -21,7 +21,7 @@ if (obj) { > /* > * Because a writer could delete object, and a writer could > * reuse these object before the RCU grace period, we > - * must check key after geting the reference on object > + * must check key after getting the reference on object > */ > if (obj->key != key) { // not the object we expected > put_ref(obj); > @@ -117,7 +117,7 @@ a race (some writer did a delete and/or a move of an object > to another chain) checking the final 'nulls' value if > the lookup met the end of chain. If final 'nulls' value > is not the slot number, then we must restart the lookup at > -the begining. If the object was moved to same chain, > +the beginning. If the object was moved to the same chain, > then the reader doesnt care : It might eventually > scan the list again without harm. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 31 Mar 2009, Jarek Poplawski wrote: > On Mon, Mar 30, 2009 at 10:11:47PM +0200, Jesper Dangaard Brouer wrote: >> >> Trival spelling fixes in RCU/rculist_nulls.txt. >> >> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> >> Reviewed-by: Jarek Poplawski <jarkao2@gmail.com> > > Hmm... still "reviewing", and maybe it's only me, but can't apply... > (v1 works OK.) Sorry, it because my email program "pine" insists on line wrapping. I have tried to adjust the preferences ("newmail-window-width" and "composer-wrap-column") but it still insists... grrr It looks like that patchwork corrected the line wrappings (http://patchwork.ozlabs.org/patch/25337/) but if I download the patch via patchwork, it also fails because a space has been added in front of all lines, hmmm... Okay, I'll try to repost using another email program (as reply to this message so patchwork will pick it up). It amazing how much time we use on these nitpicks ;-) Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt index 239f542..6389dec 100644 --- a/Documentation/RCU/rculist_nulls.txt +++ b/Documentation/RCU/rculist_nulls.txt @@ -21,7 +21,7 @@ if (obj) { /* * Because a writer could delete object, and a writer could * reuse these object before the RCU grace period, we - * must check key after geting the reference on object + * must check key after getting the reference on object */ if (obj->key != key) { // not the object we expected put_ref(obj); @@ -117,7 +117,7 @@ a race (some writer did a delete and/or a move of an object to another chain) checking the final 'nulls' value if the lookup met the end of chain. If final 'nulls' value is not the slot number, then we must restart the lookup at -the begining. If the object was moved to same chain, +the beginning. If the object was moved to the same chain, then the reader doesnt care : It might eventually scan the list again without harm.