Re: [PATCH] x86/cpu: Fix typos and improve the comments in sync_core()

[Ingo Molnar <mingo@kernel.org>]

* Ricardo Neri <ricardo.neri-calderon@linux.intel.com> wrote:

> > @@ -47,16 +47,19 @@ static inline void iret_to_self(void)
> >   *
> >   *  b) Text was modified on a different CPU, may subsequently be
> >   *     executed on this CPU, and you want to make sure the new version
> > - *     gets executed.  This generally means you're calling this in a IPI.
> > + *     gets executed.  This generally means you're calling this in an IPI.
> >   *
> >   * If you're calling this for a different reason, you're probably doing
> >   * it wrong.
> > + *
> > + * Like all of Linux's memory ordering operations, this is a
> > + * compiler barrier as well.
> >   */
> >  static inline void sync_core(void)
> >  {
> >  	/*
> >  	 * The SERIALIZE instruction is the most straightforward way to
> > -	 * do this but it not universally available.
> > +	 * do this, but it is not universally available.
> 
> Indeed, I missed this grammar error.
> 
> >  	 */
> >  	if (static_cpu_has(X86_FEATURE_SERIALIZE)) {
> >  		serialize();
> > @@ -67,10 +70,10 @@ static inline void sync_core(void)
> >  	 * For all other processors, there are quite a few ways to do this.
> >  	 * IRET-to-self is nice because it works on every CPU, at any CPL
> >  	 * (so it's compatible with paravirtualization), and it never exits
> > -	 * to a hypervisor. The only down sides are that it's a bit slow
> > +	 * to a hypervisor.  The only downsides are that it's a bit slow

And this one - it's "downsides" not "down sides".

> >  	 * (it seems to be a bit more than 2x slower than the fastest
> > -	 * options) and that it unmasks NMIs.  The "push %cs" is needed
> > -	 * because, in paravirtual environments, __KERNEL_CS may not be a
> > +	 * options) and that it unmasks NMIs.  The "push %cs" is needed,
> > +	 * because in paravirtual environments __KERNEL_CS may not be a
> 
> I didn't realize that the double spaces after the period were part of the
> style.

They are not, but *consistent* use of typographic details is part of 
the style, and here we were mixing two styles within the same comment 
block.

> FWIW,
> 
> Reviewed-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>

Thanks,

	Ingo