Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210607031537.12366-1-thunder.leizhen@huawei.com>
In-Reply-To: <20210607031537.12366-1-thunder.leizhen@huawei.com>
From:   Andrey Konovalov <andreyknvl@gmail.com>
Date:   Tue, 8 Jun 2021 00:19:02 +0300
Message-ID: <CA+fCnZcR5VfhfM-z3rjj3nKHny=upnPLxh_OBu5JqaGSAqZQiQ@mail.gmail.com>
Subject: Re: [PATCH 1/1] lib/test: Fix spelling mistakes
To:     Zhen Lei <thunder.leizhen@huawei.com>
Cc:     Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Petr Mladek <pmladek@suse.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Andrew Morton <akpm@linux-foundation.org>,
        netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
        kasan-dev <kasan-dev@googlegroups.com>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 7, 2021 at 6:18 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>
> Fix some spelling mistakes in comments:
> thats ==> that's
> unitialized ==> uninitialized
> panicing ==> panicking
> sucess ==> success
> possitive ==> positive
> intepreted ==> interpreted
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
>  lib/test_bitops.c | 2 +-
>  lib/test_bpf.c    | 2 +-
>  lib/test_kasan.c  | 2 +-
>  lib/test_kmod.c   | 6 +++---
>  lib/test_scanf.c  | 2 +-
>  5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/lib/test_bitops.c b/lib/test_bitops.c
> index 471141ddd691..3b7bcbee84db 100644
> --- a/lib/test_bitops.c
> +++ b/lib/test_bitops.c
> @@ -15,7 +15,7 @@
>   *   get_count_order/long
>   */
>
> -/* use an enum because thats the most common BITMAP usage */
> +/* use an enum because that's the most common BITMAP usage */
>  enum bitops_fun {
>         BITOPS_4 = 4,
>         BITOPS_7 = 7,
> diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> index 4dc4dcbecd12..d500320778c7 100644
> --- a/lib/test_bpf.c
> +++ b/lib/test_bpf.c
> @@ -1095,7 +1095,7 @@ static struct bpf_test tests[] = {
>         {
>                 "RET_A",
>                 .u.insns = {
> -                       /* check that unitialized X and A contain zeros */
> +                       /* check that uninitialized X and A contain zeros */
>                         BPF_STMT(BPF_MISC | BPF_TXA, 0),
>                         BPF_STMT(BPF_RET | BPF_A, 0)
>                 },
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index cacbbbdef768..72b8e808c39c 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -656,7 +656,7 @@ static void kasan_global_oob(struct kunit *test)
>  {
>         /*
>          * Deliberate out-of-bounds access. To prevent CONFIG_UBSAN_LOCAL_BOUNDS
> -        * from failing here and panicing the kernel, access the array via a
> +        * from failing here and panicking the kernel, access the array via a
>          * volatile pointer, which will prevent the compiler from being able to
>          * determine the array bounds.
>          *
> diff --git a/lib/test_kmod.c b/lib/test_kmod.c
> index 38c250fbace3..ce1589391413 100644
> --- a/lib/test_kmod.c
> +++ b/lib/test_kmod.c
> @@ -286,7 +286,7 @@ static int tally_work_test(struct kmod_test_device_info *info)
>   * If this ran it means *all* tasks were created fine and we
>   * are now just collecting results.
>   *
> - * Only propagate errors, do not override with a subsequent sucess case.
> + * Only propagate errors, do not override with a subsequent success case.
>   */
>  static void tally_up_work(struct kmod_test_device *test_dev)
>  {
> @@ -543,7 +543,7 @@ static int trigger_config_run(struct kmod_test_device *test_dev)
>          * wrong with the setup of the test. If the test setup went fine
>          * then userspace must just check the result of config->test_result.
>          * One issue with relying on the return from a call in the kernel
> -        * is if the kernel returns a possitive value using this trigger
> +        * is if the kernel returns a positive value using this trigger
>          * will not return the value to userspace, it would be lost.
>          *
>          * By not relying on capturing the return value of tests we are using
> @@ -585,7 +585,7 @@ trigger_config_store(struct device *dev,
>          * Note: any return > 0 will be treated as success
>          * and the error value will not be available to userspace.
>          * Do not rely on trying to send to userspace a test value
> -        * return value as possitive return errors will be lost.
> +        * return value as positive return errors will be lost.
>          */
>         if (WARN_ON(ret > 0))
>                 return -EINVAL;
> diff --git a/lib/test_scanf.c b/lib/test_scanf.c
> index 48ff5747a4da..84fe09eaf55e 100644
> --- a/lib/test_scanf.c
> +++ b/lib/test_scanf.c
> @@ -600,7 +600,7 @@ static void __init numbers_prefix_overflow(void)
>         /*
>          * 0x prefix in a field of width 2 using %i conversion: first field
>          * converts to 0. Next field scan starts at the character after "0x",
> -        * which will convert if can be intepreted as decimal but will fail
> +        * which will convert if can be interpreted as decimal but will fail
>          * if it contains any hex digits (since no 0x prefix).
>          */
>         test_number_prefix(long long,   "0x67", "%2lli%lli", 0, 67, 2, check_ll);
> --
> 2.25.1

For lib/test_kasan.c:

Acked-by: Andrey Konovalov <andreyknvl@gmail.com>