Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp28139pxb; Wed, 30 Mar 2022 21:59:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztlSUPqWHN7WAXLl4kqHLC1e9NYHpQn8Eb4EbdTIsIoDaBVHjADIYrhzEA318E0+krc2p/ X-Received: by 2002:a63:586:0:b0:386:326:f486 with SMTP id 128-20020a630586000000b003860326f486mr9376351pgf.3.1648702782541; Wed, 30 Mar 2022 21:59:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648702782; cv=none; d=google.com; s=arc-20160816; b=q5ZR4FG+N8ABTYRnmG1RwYKNWEuc6UWdpCWXkJUYQ7RxqS06iBu6QlIX+DludBa37+ DsTZE5L33DA0qudCQuAOUpeNhNCOMHgbZsC9D4i6bnKooiwu36SgJ7s/AydGRqhdR+t4 vspFvBeU4lp6JQlisQBTDUUFLTeMQfRx/04wzef8DagDCkAZYD6/f11gO8oWcs5iyJzR OcvFNmBhjRz1/V4fy7nYhw9arKNqcLJ/HbP/1AiS0DGQqb4dKSUF7n1KTZZlYlOaXKhE 7PnY1c4b5Z93iU38lO9U8NI4svzR3/IS1BOtEkrF+ljlhodMPYHVLng5d4uZfQ4IQntz uCUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=zd9bA/vVsUljfZ2zHhaCGxU4BtZMVvpzyOofaCZaWSI=; b=kBNisKht0YtalZn0Tb6+62fM6zn5moPk003gLfV1ZMx2ckJecy5xnlI4WddkGMv6Lz kizOAjlWs8lvCSQFocjf4ZT1MgmJASf3VmAh4axZT47exKQTE6nWARw5E04TsJ5q6Wh/ BU+zwN4FUjcaCbvZlBhEaq5fcvYouCfp0a8ROeJb3hgaH1X4t+s6e7b8rZTfaoNAtBKw TuahXP3kpjNwt10+N/4+td1135WVHV49YUTNhYptSXpmV8w0z5QVqotOJLoY+cG4BKlN NNW+bge6lvSi49WFA2wNIptIADimgdvPT1fi1Zh0GJI4RHDQLopUXpbb3WXtFMmhTdHS LUtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="jk/9Tmso"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b11-20020a170902bd4b00b00153b2d164a3si20957318plx.171.2022.03.30.21.59.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 21:59:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="jk/9Tmso"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D2AE8247807; Wed, 30 Mar 2022 20:36:48 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238555AbiC2W4I (ORCPT + 99 others); Tue, 29 Mar 2022 18:56:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238531AbiC2W4G (ORCPT ); Tue, 29 Mar 2022 18:56:06 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97FDDBA33A for ; Tue, 29 Mar 2022 15:54:22 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id p15so38004005ejc.7 for ; Tue, 29 Mar 2022 15:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zd9bA/vVsUljfZ2zHhaCGxU4BtZMVvpzyOofaCZaWSI=; b=jk/9TmsoatIgO07065kxR/5mB1wQ8q4FUWIvnM39nXT7UfRE+1LkZl/noVHNBe5oT3 GH7nAcSb6gtqiNbisLO2gWbXMx8YcXx6uQ2Lyyj+sNMuf1JFkbhUscK/ZZK/njpz1XgI HlWL7fwMMn2nk+x+Rdox8d8O8cyRaBtZFgTT8AOObpFDivUSvnkz++BBkIZWHrJCMdEV LbmUlyzSAzIJrNbAm3a2J7dv/cypv+lwBYSxsEClhOFnBWXtN7J1Zlj11np+Wf7zGT2B vzxftyArV2jMUz4zQrAQ/+lu4yjtPE8xV29c0K6DeI1RQB+t8L20MwR4HS2IpJ7r9IgB bnJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zd9bA/vVsUljfZ2zHhaCGxU4BtZMVvpzyOofaCZaWSI=; b=sQAhvUukHppPxMXJl7Qg8G65ZplTF35Tbbx9MTeBOAF93npdV0vR19spuBPM5Ufc37 KknvucTCOtXC0r1isz/W65baNi1OrJuIegSSP+rZAqECvoZMvxarjen2u1RTnZ6G8EK1 q+92yXfWlSBmUxdyBkONjkGOVZzAjk6uzosvNDBsBBMYRv/xl9HZLd1T1hOe6NOyODd1 wR9x6ZYpqiU3W2Gg7C6hFXfCD8xoRKwXXpq81bGj0DWFdd2s8hOJOzBhOP21hOkhYsNV WTY+A2Ayv4ZpJGhCdBy+OBysXRs1d2kpJZTS5f1LiKxu/tEgRZ3dCorvToBmEvO3vv+g WCOg== X-Gm-Message-State: AOAM530f6YGXlbvjY5lJ1d1T3u6LVKtZcmVGmouPBu3/UQlMb1H5e5MW 5XgVkLC8iQQuDO2RbB0ZPe619Mx+PygsBQ5FELGCbg== X-Received: by 2002:a17:907:1622:b0:6df:d1a2:d4a3 with SMTP id hb34-20020a170907162200b006dfd1a2d4a3mr35715153ejc.542.1648594460875; Tue, 29 Mar 2022 15:54:20 -0700 (PDT) MIME-Version: 1.0 References: <20220329103919.2376818-1-lv.ruyi@zte.com.cn> In-Reply-To: From: Daniel Latypov Date: Tue, 29 Mar 2022 17:54:09 -0500 Message-ID: Subject: Re: [PATCH] kunit: tool: add null pointer check 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 , Zeal Robot Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 29, 2022 at 2:29 PM Daniel Latypov wrote: > > On Tue, Mar 29, 2022 at 5:39 AM wrote: > > > > From: Lv Ruyi > > > > 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 > > Signed-off-by: Lv Ruyi > > --- > > 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?" More concretely, I'm thinking something like this: diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c index 22640c9ee819..a5c29a32a33a 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 ERR_PTR(-ENOMEM); memcpy(copy, suite, sizeof(*copy)); filtered = kcalloc(n + 1, sizeof(*filtered), GFP_KERNEL); + if (!filtered) + return ERR_PTR(-ENOMEM); n = 0; kunit_suite_for_each_test_case(suite, test_case) { @@ -106,14 +110,16 @@ kunit_filter_subsuite(struct kunit_suite * const * const subsuite, filtered = kmalloc_array(n + 1, sizeof(*filtered), GFP_KERNEL); if (!filtered) - return NULL; + return ERR_PTR(-ENOMEM); n = 0; for (i = 0; subsuite[i] != NULL; ++i) { if (!glob_match(filter->suite_glob, subsuite[i]->name)) continue; filtered_suite = kunit_filter_tests(subsuite[i], filter->test_glob); - if (filtered_suite) + if (IS_ERR(filtered_suite)) + return ERR_CAST(filtered_suite); + else if (filtered_suite) filtered[n++] = filtered_suite; } filtered[n] = NULL; @@ -166,6 +172,8 @@ static struct suite_set kunit_filter_suites(const struct suite_set *suite_set, for (i = 0; i < max; ++i) { filtered_subsuite = kunit_filter_subsuite(suite_set->start[i], &filter); + if (IS_ERR(filtered_subsuite)) + return filtered; // TODO: how do we signal this? if (filtered_subsuite) *copy++ = filtered_subsuite; } > Or maybe just adding some pr_err() calls is sufficient.