linux-kernel - Re: [PATCH] arc: include/asm: Couple of spelling fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c2e269cc-779a-0213-982b-84278efac595@infradead.org>
Date:   Mon, 22 Mar 2021 11:43:10 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Bhaskar Chowdhury <unixbhaskar@...il.com>, vgupta@...opsys.com,
        linux-snps-arc@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arc: include/asm: Couple of spelling fixes

On 3/22/21 5:32 AM, Bhaskar Chowdhury wrote:
> 
> s/interrpted/interrupted/
> s/defintion/definition/
> 
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@...il.com>

Acked-by: Randy Dunlap <rdunlap@...radead.org>

> ---
>  arch/arc/include/asm/cmpxchg.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
> index 9b87e162e539..dfeffa25499b 100644
> --- a/arch/arc/include/asm/cmpxchg.h
> +++ b/arch/arc/include/asm/cmpxchg.h
> @@ -116,7 +116,7 @@ static inline unsigned long __xchg(unsigned long val, volatile void *ptr,
>   *
>   * Technically the lock is also needed for UP (boils down to irq save/restore)
>   * but we can cheat a bit since cmpxchg() atomic_ops_lock() would cause irqs to
> - * be disabled thus can't possibly be interrpted/preempted/clobbered by xchg()
> + * be disabled thus can't possibly be interrupted/preempted/clobbered by xchg()
>   * Other way around, xchg is one instruction anyways, so can't be interrupted
>   * as such
>   */
> @@ -143,7 +143,7 @@ static inline unsigned long __xchg(unsigned long val, volatile void *ptr,
>  /*
>   * "atomic" variant of xchg()
>   * REQ: It needs to follow the same serialization rules as other atomic_xxx()
> - * Since xchg() doesn't always do that, it would seem that following defintion
> + * Since xchg() doesn't always do that, it would seem that following definition
>   * is incorrect. But here's the rationale:
>   *   SMP : Even xchg() takes the atomic_ops_lock, so OK.
>   *   LLSC: atomic_ops_lock are not relevant at all (even if SMP, since LLSC
> --


-- 
~Randy