All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Latypov <dlatypov@google.com>
To: cgel.zte@gmail.com
Cc: brendanhiggins@google.com, linux-kselftest@vger.kernel.org,
	kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org,
	Lv Ruyi <lv.ruyi@zte.com.cn>, Zeal Robot <zealci@zte.com.cn>
Subject: Re: [PATCH] kunit: tool: add null pointer check
Date: Tue, 29 Mar 2022 14:29:12 -0500	[thread overview]
Message-ID: <CAGS_qxpCHgp7ToQV9UALPy-4nyHDcdpWOCCd3duz-L6EgYPpOg@mail.gmail.com> (raw)
In-Reply-To: <20220329103919.2376818-1-lv.ruyi@zte.com.cn>

On Tue, Mar 29, 2022 at 5:39 AM <cgel.zte@gmail.com> wrote:
>
> From: Lv Ruyi <lv.ruyi@zte.com.cn>
>
> kmalloc and kcalloc is a memory allocation function which can return NULL
> when some internal memory errors happen. Add null pointer check to avoid
> dereferencing null pointer.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
> ---
>  lib/kunit/executor.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
> index 22640c9ee819..be21d0451367 100644
> --- a/lib/kunit/executor.c
> +++ b/lib/kunit/executor.c
> @@ -71,9 +71,13 @@ kunit_filter_tests(struct kunit_suite *const suite, const char *test_glob)
>
>         /* Use memcpy to workaround copy->name being const. */
>         copy = kmalloc(sizeof(*copy), GFP_KERNEL);
> +       if (!copy)
> +               return NULL;

While this is technically correct to check, in this context it's less clear.
If we can't allocate this memory, we likely can't run any subsequent
tests, either because the test cases will want to allocate some memory
and/or KUnit will need to allocate some for internal bookkeeping.

The existing code (and by extension this patch) "handles" OOM
situations by silently dropping test suites/cases.
So I sort of intentionally figured we should let it crash early in
this case since that's probably more debuggable.

This code does check for NULL returns earlier on in the call chain, i.e.

first in kunit_filter_suites()
   158          copy = kmalloc_array(max, sizeof(*filtered.start), GFP_KERNEL);
   159          filtered.start = copy;
   160          if (!copy) { /* won't be able to run anything, return
an empty set */
   161                  filtered.end = copy;
   162                  return filtered;
   163          }

and second in kunit_filter_subsuite()
   107          filtered = kmalloc_array(n + 1, sizeof(*filtered), GFP_KERNEL);
   108          if (!filtered)
   109                  return NULL;

The first kmalloc_array() is our first allocation in this file.
If we can't handle that, then things are really going wrong, and I
assumed there'd be plenty of debug messages in dmesg, so silently
returning is probably fine.
The second one also felt similar.

So I think that
* it's highly unlikely that we pass those checks and fail on these new
ones (we're not allocating much)
* if we do fail, this is now harder to debug since it's partially
running tests, partially not

Should we instead rework the code to more clearly signal allocation
errors instead of overloading NULL to mean "no matches or error?"
Or maybe just adding some pr_err() calls is sufficient.

>         memcpy(copy, suite, sizeof(*copy));
>
>         filtered = kcalloc(n + 1, sizeof(*filtered), GFP_KERNEL);
> +       if (!filtered)
> +               return NULL;
>
>         n = 0;
>         kunit_suite_for_each_test_case(suite, test_case) {
> --
> 2.25.1
>

  reply	other threads:[~2022-03-29 19:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 10:39 [PATCH] kunit: tool: add null pointer check cgel.zte
2022-03-29 19:29 ` Daniel Latypov [this message]
2022-03-29 21:32   ` Brendan Higgins
2022-03-29 22:54   ` Daniel Latypov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGS_qxpCHgp7ToQV9UALPy-4nyHDcdpWOCCd3duz-L6EgYPpOg@mail.gmail.com \
    --to=dlatypov@google.com \
    --cc=brendanhiggins@google.com \
    --cc=cgel.zte@gmail.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lv.ruyi@zte.com.cn \
    --cc=zealci@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.