linux-kernel - Re: [PATCH] kunit: bail out of test filtering logic quicker if OOM

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFd5g44aO9KOhxuM7NF_=D2QoA3gTDv8cQ+3qqq+zYA4C54L_Q@mail.gmail.com>
Date:   Wed, 11 May 2022 17:12:05 -0400
From:   Brendan Higgins <brendanhiggins@...gle.com>
To:     Daniel Latypov <dlatypov@...gle.com>
Cc:     davidgow@...gle.com, linux-kernel@...r.kernel.org,
        kunit-dev@...glegroups.com, linux-kselftest@...r.kernel.org,
        skhan@...uxfoundation.org, Zeal Robot <zealci@....com.cn>,
        Lv Ruyi <lv.ruyi@....com.cn>
Subject: Re: [PATCH] kunit: bail out of test filtering logic quicker if OOM

On Wed, Apr 6, 2022 at 7:22 PM Daniel Latypov <dlatypov@...gle.com> wrote:
>
> When filtering what tests to run (suites and/or cases) via
> kunit.filter_glob (e.g. kunit.py run <glob>), we allocate copies of
> suites.
>
> These allocations can fail, and we largely don't handle that.
> Note: realistically, this probably doesn't matter much.
> We're not allocating much memory and this happens early in boot, so if
> we can't do that, then there's likely far bigger problems.
>
> This patch makes us immediately bail out from the top-level function
> (kunit_filter_suites) with -ENOMEM if any of the underlying kmalloc()
> calls return NULL.
>
> Implementation note: we used to return NULL pointers from some functions
> to indicate either that all suites/tests were filtered out or there was
> an error allocating the new array.
>
> We'll log a short error in this case and not run any tests or print a
> TAP header. From a kunit.py user's perspective, they'll get a message
> about missing/invalid TAP output and have to dig into the test.log to
> see it. Since hitting this error seems so unlikely, it's probably fine
> to not invent a way to plumb this error message more visibly.
>
> See also: https://lore.kernel.org/linux-kselftest/20220329103919.2376818-1-lv.ruyi@zte.com.cn/
>
> Signed-off-by: Daniel Latypov <dlatypov@...gle.com>
> Reported-by: Zeal Robot <zealci@....com.cn>
> Signed-off-by: Lv Ruyi <lv.ruyi@....com.cn>

Reviewed-by: Brendan Higgins <brendanhiggins@...gle.com>