* Ricardo Neri <ricardo.neri-calde...@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-calde...@linux.intel.com>
Thanks,
Ingo
