Messages in this thread | | | Date | Wed, 19 Aug 2020 09:55:37 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86/cpu: Fix typos and improve the comments in sync_core() |
| |
* 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
| |