Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2463295pxb; Thu, 11 Feb 2021 13:03:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJxEwnU92A1ATwCdryRW5NM7vKWUOOQkQVQfE5HXDf2FLAUSVkyXBxJqupGdsdvefyRTIlCL X-Received: by 2002:a17:906:cc50:: with SMTP id mm16mr10201918ejb.366.1613077429334; Thu, 11 Feb 2021 13:03:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613077429; cv=none; d=google.com; s=arc-20160816; b=m2YkZR+SYQTQFxKwzlSUCq+n9DXw8S+o7RnItjTAyNef+Pz6+1LmMn5MM82snTACvL 15HBAN6KuAaw0kZS29TGp8mnk37qrqbpJkHEsXOazh1uD+IHeXYwLvxqgll1Ah3d5av3 aWm+SVNHXWvaZ3AparPEKBc3A186jyumitMNcKTYBFVSpL2q/0nqIrw6Pl6bE8BBirXb 0aAePnSU2nF1TRAH7DrnltWEzTm2LDsp1xoyYT0NOVsIg/IgYrUUZ5Zzt5hMSdWkOM3F 0zscetuxfVrE1rLosNF7G/OZUyGsu/hEgtfn6G0qCvTpdvf1O8k1laYhxLkGxfxZ/mCQ xjow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=elQYs+CRXIUFdDZB9CGMtfOprXMD+hm3lRs8yHOI0LA=; b=ifT1SqH0g8WPQ5VrNzEpc6LFbKUMBInT5db6gkWC1JZHP59lgVq4RfCoepBEYXXJ+3 YyWl9OSjSOVmPAqZe1oUxvzXpxfXclIm6p+TEUBDQoPj7eYBHWBHtvGhSR9fZovQyBa9 Ecgt092zvyd6ytfdMAYI2T8JEiAtoicDDTfZK2idQl7vlF3LvPzte/bfUQttQT7IBnES U9kkAV6leh/agIIwzP/g4M4SqmXnLUsZlKLHu3T6jAP59fMGlo2XKPAAYdNrMxyV8aVA h29VdbEJ5rbUzukqVdL68ulPWVFhT5DM2k1VepdLhxaM1iX/evtyenQBqsG1qolAC/7C /xMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=okWuQ3wA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f8si4566526edq.140.2021.02.11.13.03.12; Thu, 11 Feb 2021 13:03:49 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=okWuQ3wA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229790AbhBKU7Z (ORCPT + 99 others); Thu, 11 Feb 2021 15:59:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229707AbhBKU7X (ORCPT ); Thu, 11 Feb 2021 15:59:23 -0500 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D00D6C061756 for ; Thu, 11 Feb 2021 12:58:43 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id q7so7192338iob.0 for ; Thu, 11 Feb 2021 12:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=elQYs+CRXIUFdDZB9CGMtfOprXMD+hm3lRs8yHOI0LA=; b=okWuQ3wA1SEGnMAhPUpBmEag/3+8gkpbLKpSw3cSONQDEP5aFC3EA1MOtaaZ/THUyt IjUZuniBofMCvYCpy9tCzsdHNmQ2rw1/9k9sZhsslkY8yDXwnBSxKF1nfE41WG0/zQIn WIh5UHW+XyvpFwPkL/3YYnoV6N/oukqmrFStpIK4Ox2MH8A49WtEpI3FiEnYC+gxyL25 ADpYrB35N37xQKXfGywu3vGqObItzfthVNkIanlugZYXxMJsAbbnRdA5G+CNYtdOrJNT HSf/VTBvTKp2As62gfR1z9qR6qicPg5dGDwSHvQnC7wYSuxz7blL6rsqRlOSxxj0e5bm sG0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=elQYs+CRXIUFdDZB9CGMtfOprXMD+hm3lRs8yHOI0LA=; b=mQjtDVbZlu3Sm97KNSolVfpt4uDQ/Qd98elgy0a+yT51PHnVzsVCYJ9o/soVKy6Si0 B9djJmRrmeAdk5cEoZwcey2PzlSD2LGcMLNLCGuJVRcgf6sJKPu6Wvv9CEFnFhwKfcVi 9wo/cquHnrea5AVCCQWE224ppMKLRtfURYeq0dq5hMZvgt7mZtGcyVnR+7xFyGG5yCTg a5GU6gLSfgi/DCvR6m/Q4VZaqBCMH+QOJShefprE0HozfmKWmUKF+a1RWuWrFcJIJiNn 15Z46kGTxPmg56VqU1xfSV4CBvIk64J3RC1n8Wj1kRmXLn5L/2oLdIGDzwDG1Mu1Laoh FU2g== X-Gm-Message-State: AOAM533bm4pYP0+HUzEM+N5JkpST+UF21OXHVi+UWqj6zm1TYJ6OkRew E+8rqDv5GRHNsUHuTgVq1KAmvGTRXECTuuy5UJsCTg== X-Received: by 2002:a6b:f112:: with SMTP id e18mr6772051iog.57.1613077122916; Thu, 11 Feb 2021 12:58:42 -0800 (PST) MIME-Version: 1.0 References: <20210209221443.78812-1-dlatypov@google.com> <20210209221443.78812-2-dlatypov@google.com> In-Reply-To: From: Daniel Latypov Date: Thu, 11 Feb 2021 12:58:31 -0800 Message-ID: Subject: Re: [PATCH v3 1/2] kunit: support failure from dynamic analysis tools To: Alan Maguire Cc: David Gow , Brendan Higgins , Linux Kernel Mailing List , KUnit Development , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , Uriel Guajardo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 11, 2021 at 7:40 AM Alan Maguire wrot= e: > > On Thu, 11 Feb 2021, David Gow wrote: > > > On Wed, Feb 10, 2021 at 6:14 AM Daniel Latypov wr= ote: > > > > > > From: Uriel Guajardo > > > > > > Add a kunit_fail_current_test() function to fail the currently runnin= g > > > test, if any, with an error message. > > > > > > This is largely intended for dynamic analysis tools like UBSAN and fo= r > > > fakes. > > > E.g. say I had a fake ops struct for testing and I wanted my `free` > > > function to complain if it was called with an invalid argument, or > > > caught a double-free. Most return void and have no normal means of > > > signalling failure (e.g. super_operations, iommu_ops, etc.). > > > > > > Key points: > > > * Always update current->kunit_test so anyone can use it. > > > * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it = for > > > CONFIG_KASAN=3Dy > > > > > > * Create a new header so non-test code doesn't hav= e > > > to include all of (e.g. lib/ubsan.c) > > > > > > * Forward the file and line number to make it easier to track down > > > failures > > > > > > * Declare the helper function for nice __printf() warnings about mism= atched > > > format strings even when KUnit is not enabled. > > > > > > Example output from kunit_fail_current_test("message"): > > > [15:19:34] [FAILED] example_simple_test > > > [15:19:34] # example_simple_test: initializing > > > [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:= 24: message > > > [15:19:34] not ok 1 - example_simple_test > > > > > > Co-developed-by: Daniel Latypov > > > Signed-off-by: Uriel Guajardo > > > Signed-off-by: Daniel Latypov > > > --- > > > include/kunit/test-bug.h | 30 ++++++++++++++++++++++++++++++ > > > lib/kunit/test.c | 37 +++++++++++++++++++++++++++++++++---- > > > 2 files changed, 63 insertions(+), 4 deletions(-) > > > create mode 100644 include/kunit/test-bug.h > > > > > > diff --git a/include/kunit/test-bug.h b/include/kunit/test-bug.h > > > new file mode 100644 > > > index 000000000000..18b1034ec43a > > > --- /dev/null > > > +++ b/include/kunit/test-bug.h > > > @@ -0,0 +1,30 @@ > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > +/* > > > + * KUnit API allowing dynamic analysis tools to interact with KUnit = tests > > > + * > > > + * Copyright (C) 2020, Google LLC. > > > + * Author: Uriel Guajardo > > > + */ > > > + > > > +#ifndef _KUNIT_TEST_BUG_H > > > +#define _KUNIT_TEST_BUG_H > > > + > > > +#define kunit_fail_current_test(fmt, ...) \ > > > + __kunit_fail_current_test(__FILE__, __LINE__, fmt, ##__VA_ARG= S__) > > > + > > > +#if IS_ENABLED(CONFIG_KUNIT) > > > > As the kernel test robot has pointed out on the second patch, this > > probably should be IS_BUILTIN(), otherwise this won't build if KUnit > > is a module, and the code calling it isn't. > > > > This does mean that things like UBSAN integration won't work if KUnit > > is a module, which is a shame. > > > > (It's worth noting that the KASAN integration worked around this by > > only calling inline functions, which would therefore be built-in even > > if the rest of KUnit was built as a module. I don't think it's quite > > as convenient to do that here, though.) > > > > Right, static inline'ing __kunit_fail_current_test() seems problematic > because it calls other exported functions; more below.... > > > > + > > > +extern __printf(3, 4) void __kunit_fail_current_test(const char *fil= e, int line, > > > + const char *fmt, = ...); > > > + > > > +#else > > > + > > > +static __printf(3, 4) void __kunit_fail_current_test(const char *fil= e, int line, > > > + const char *fmt, = ...) > > > +{ > > > +} > > > + > > > +#endif > > > + > > > + > > > +#endif /* _KUNIT_TEST_BUG_H */ > > > diff --git a/lib/kunit/test.c b/lib/kunit/test.c > > > index ec9494e914ef..5794059505cf 100644 > > > --- a/lib/kunit/test.c > > > +++ b/lib/kunit/test.c > > > @@ -7,6 +7,7 @@ > > > */ > > > > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -16,6 +17,38 @@ > > > #include "string-stream.h" > > > #include "try-catch-impl.h" > > > > > > +/* > > > + * Fail the current test and print an error message to the log. > > > + */ > > > +void __kunit_fail_current_test(const char *file, int line, const cha= r *fmt, ...) > > > +{ > > > + va_list args; > > > + int len; > > > + char *buffer; > > > + > > > + if (!current->kunit_test) > > > + return; > > > + > > > + kunit_set_failure(current->kunit_test); > > > + > > currently kunit_set_failure() is static, but it could be inlined I > suspect. > > > > + /* kunit_err() only accepts literals, so evaluate the args fi= rst. */ > > > + va_start(args, fmt); > > > + len =3D vsnprintf(NULL, 0, fmt, args) + 1; > > > + va_end(args); > > > + > > > + buffer =3D kunit_kmalloc(current->kunit_test, len, GFP_KERNEL= ); > > kunit_kmalloc()/kunit_kfree() are exported also, but we could probably > dodge allocation with a static buffer. In fact since we end up > using an on-stack buffer for logging in kunit_log_append(), it might make Ah, right there's those as well. I originally had it on the stack, but the fact we use an on-stack buffer is why I switched over. I originally had it as a macro as you do now but liked the __printf() annotation to be closer* to the user's code and now down through several layers of macros (kunit_fail_current_test =3D> kunit_err =3D> kunit_printk =3D> kunit_log =3D> printk). And then having it on the stack and then calling into kunit_log_append() would (naively) use up 2 *KUNIT_LOG_SIZE stack space. So only a minor concern, and so I like the simpler def using a macro given the messiness. (But we'd give up the __printf checking when compiling w/o KUnit, which is a bit sad) *E.g. if one misuses kunit_err(), we get this message which is understandable, but a bit more noisy than I'd prefer. ../include/linux/kern_levels.h:5:18: warning: format =E2=80=98%d=E2=80=99 e= xpects argument of type =E2=80=98int=E2=80=99, but argument 3 has type =E2=80=98ch= ar *=E2=80=99 [-Wformat=3D] 5 | #define KERN_SOH "\001" /* ASCII Start Of Header */ | ^~~~~~ ../include/kunit/test.h:621:10: note: in definition of macro =E2=80=98kunit= _log=E2=80=99 621 | printk(lvl fmt, ##__VA_ARGS__); \ | ^~~ ../include/kunit/test.h:662:2: note: in expansion of macro =E2=80=98kunit_p= rintk=E2=80=99 662 | kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~ ../include/linux/kern_levels.h:11:18: note: in expansion of macro =E2=80=98= KERN_SOH=E2=80=99 11 | #define KERN_ERR KERN_SOH "3" /* error conditions */ | ^~~~~~~~ ../include/kunit/test.h:662:15: note: in expansion of macro =E2=80=98KERN_E= RR=E2=80=99 662 | kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__) | ^~~~~~~~ ../lib/kunit/kunit-example-test.c:30:2: note: in expansion of macro =E2=80= =98kunit_err=E2=80=99 30 | kunit_err(test, "invalid format string: %d", "hi"); | ^~~~~~~~~ > sense to #define __kunit_fail_current_test() instead, i.e. > > #define __kunit_fail_current_test(file, line, fmt, ...) \ > do { \ > kunit_set_failure(current->kunit_test); \ > kunit_err(current->kunit_test, "%s:%d: " fmt, \ > ##__VA_ARGS__); \ > } while (0) > > > > + if (!buffer) > > > + return; > > > + > > > + va_start(args, fmt); > > > + vsnprintf(buffer, len, fmt, args); > > > + va_end(args); > > > + > > > + kunit_err(current->kunit_test, "%s:%d: %s", file, line, buffe= r); > > To get kunit_err() to work, we'd need to "static inline" > kunit_log_append(). It's not a trivial function, but on the plus > side it doesn't call any other exported kunit functions AFAICT. > > So while any of the above suggestions aren't intended to block > Daniel's work, does the above seem reasonable for a follow-up > series to get UBSAN working with module-based KUnit? Thanks! Ack, so sounds like we'd want to go ahead with making it only work w/ CONFIG_KUNIT=3Dy? I can simplify it down into a macro since the __printf() bit isn't too big of a deal. And then it'd let us only depend on kunit_log_append(), making it easier to get CONFIG_KUNIT=3Dm working. Thanks both for digging into this! I saw KTR's email and was dreading having to dig into what the smallest needed change would be. > > Alan