Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp120722imp; Tue, 19 Feb 2019 19:40:59 -0800 (PST) X-Google-Smtp-Source: AHgI3IZdY9AI9xBQFQXoDkLeNsxnwOtIQfnDkFCmTn6yt79poOIV698K2OiSMULYrJKBDpvRencJ X-Received: by 2002:a65:60c5:: with SMTP id r5mr27599090pgv.427.1550634059257; Tue, 19 Feb 2019 19:40:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550634059; cv=none; d=google.com; s=arc-20160816; b=RVa0kO2PwGD2N5J57E9B832CUVpMnhEZHiT2337x5tQg/kiQZmHyQHhe1MbrtyKTZ9 ml1SOi8NOWErmNwOzzKmNHpe30N/n/nuuhm369wmx0tOq+RNaNoHjerWU68BY9711jm7 mCvwp4NLNwWUjWo7B4xG5qwTVfXkpjvSpIUW8DJA0ZlLlkI2mASJbddJYlyOTk8l2jNp CEZmrTbDF6ViVNzX51F25Lhhxi6W4aNw3x2vrhbCwYSqJGvb07KC9XqvDkHyzECn1Kxw q4M4a8FdoLiLbvKZanaOreRp+XNBlGI3R4n07a4ikASTwwyluoBnvQ3GokXGvVyN/5ls Socw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=j8vhQ3tmgzBOdGYD4wICZoCDzu7fbBenNd993tJCq28=; b=T70RuqhNIsbtcsKfPwhY4pHwr1Ld/gERwzkwAsArx4VhBisfFSFUojPkyIppYJ4rdF gsGYsSAfIIIftOzhjslHBetq6bu3r7QqV3XthJuE/sI0KxhM9kn+yw0RBfIYAiZ3BGj8 H1rVC1f6ZQF0XYLdU8ghci3lUllhdbPwwDX9GiBbPdKWWTS10U+n8SmVGjNULbg2jsFf 7a3h5teHpH1eJnueayDUe4KxqNPQsSGMeg2xtAnGBDxtFLe7nkHvTfSiaIf/yJgzRQ+L 41mGUMaOle3Yf9N4wkL2GA/Jc3AOm75+o4FSEqfic0WR2LBdENa6u8c8C02XcMAC0Z0m D5AA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=nzfFlIir; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id s72si12910189pfa.263.2019.02.19.19.40.43; Tue, 19 Feb 2019 19:40:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=nzfFlIir; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1730415AbfBTDjc (ORCPT + 99 others); Tue, 19 Feb 2019 22:39:32 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:46280 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729506AbfBTDjb (ORCPT ); Tue, 19 Feb 2019 22:39:31 -0500 Received: by mail-ot1-f65.google.com with SMTP id c18so16335075otl.13 for ; Tue, 19 Feb 2019 19:39:31 -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; bh=j8vhQ3tmgzBOdGYD4wICZoCDzu7fbBenNd993tJCq28=; b=nzfFlIirguGhBPx/5W3M/bUq7OLn4F7BPMf3izt5IwZIb8WdeaUlMr9mMcM5bn9uwn DwrAo/qVqQED75HENHT/fAxZFMfR7rJFn8pbv899AkEv3E5a4EDJVJ5IB0Bq5u8wdVP9 KXOkMtfeANKDhE/XX4Jv6h5nLEi1KFA/rcDszChNkF3bsxNg8d/u/xmpXFWW9bWUXEe4 ZTWPBWlyn5pVjVkUDiWOFQlNsL5x+GrhsT5Nzp15/br/xXnTOYRX/DqbCojao7l0x58n 1ahUDlvfpr1577Dj31Jmhe7OutOIxAGh83aGppTy641NALWfdzr2wmsnC/3td/GpcrjV 9pPQ== 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; bh=j8vhQ3tmgzBOdGYD4wICZoCDzu7fbBenNd993tJCq28=; b=RHnKBy1OOOfRS9e9y4l192OMxMYHxtZmf8c5p4hYb/9YpOpkfDXFT6F7Stj22SbomF 9WXgtqyRCyCKO5tQuFKPi9AHNu6cyDzK5pdNINTQ5HhcPzC7uwDejUD+BjNFF7fhhP4I NQIWJJM2/0oNFQosIcUEgnCg7MPUBeVLMPKzoCn99ZpaNgwmJJ9/I4zvxpE6HDNqtHgZ AsdUBkOK0/sBiQQO2yjzPTnc5rqwGjaj+ewPoTlcvtOJ7FYxekje/Rd47UJyNCeQNXq6 4g8jgpsgkY/FBaHdmM3UCHPPTybZ4VtDHRepy0TuAPa65iSzu0AUMK8DANNTQh49no5O ezOQ== X-Gm-Message-State: AHQUAuaTd7Xj+dY6oQ2ElKWQjp1bAa1Mu5KFR3wNZWig1BeTi5YiHEb8 PC94XFzh/ZhxKYUuod1vDXuWeUSxjUR+S4OCVYFlCA== X-Received: by 2002:a05:6830:1258:: with SMTP id s24mr20546463otp.364.1550633970534; Tue, 19 Feb 2019 19:39:30 -0800 (PST) MIME-Version: 1.0 References: <20190214213729.21702-1-brendanhiggins@google.com> <20190214213729.21702-9-brendanhiggins@google.com> In-Reply-To: From: Brendan Higgins Date: Tue, 19 Feb 2019 19:39:19 -0800 Message-ID: Subject: Re: [RFC v4 08/17] kunit: test: add support for test abort To: Frank Rowand Cc: Kees Cook , Luis Chamberlain , shuah@kernel.org, Rob Herring , Kieran Bingham , Greg KH , Joel Stanley , Michael Ellerman , Joe Perches , brakmo@fb.com, Steven Rostedt , "Bird, Timothy" , Kevin Hilman , Julia Lawall , linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, Linux Kernel Mailing List , Jeff Dike , Richard Weinberger , linux-um@lists.infradead.org, Daniel Vetter , dri-devel , Dan Williams , linux-nvdimm , Knut Omang , devicetree , Petr Mladek , Sasha Levin , Amir Goldstein , dan.carpenter@oracle.com, wfg@linux.intel.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand wrote: > > On 2/14/19 1:37 PM, Brendan Higgins wrote: > > Add support for aborting/bailing out of test cases. Needed for > > implementing assertions. > > > > Signed-off-by: Brendan Higgins > > --- > > Changes Since Last Version > > - This patch is new introducing a new cross-architecture way to abort > > out of a test case (needed for KUNIT_ASSERT_*, see next patch for > > details). > > - On a side note, this is not a complete replacement for the UML abort > > mechanism, but covers the majority of necessary functionality. UML > > architecture specific featurs have been dropped from the initial > > patchset. > > --- > > include/kunit/test.h | 24 +++++ > > kunit/Makefile | 3 +- > > kunit/test-test.c | 127 ++++++++++++++++++++++++++ > > kunit/test.c | 208 +++++++++++++++++++++++++++++++++++++++++-- > > 4 files changed, 353 insertions(+), 9 deletions(-) > > create mode 100644 kunit/test-test.c > > < snip > > > > diff --git a/kunit/test.c b/kunit/test.c > > index d18c50d5ed671..6e5244642ab07 100644 > > --- a/kunit/test.c > > +++ b/kunit/test.c > > @@ -6,9 +6,9 @@ > > * Author: Brendan Higgins > > */ > > > > -#include > > #include > > -#include > > +#include > > +#include > > #include > > > > static bool kunit_get_success(struct kunit *test) > > @@ -32,6 +32,27 @@ static void kunit_set_success(struct kunit *test, bool success) > > spin_unlock_irqrestore(&test->lock, flags); > > } > > > > +static bool kunit_get_death_test(struct kunit *test) > > +{ > > + unsigned long flags; > > + bool death_test; > > + > > + spin_lock_irqsave(&test->lock, flags); > > + death_test = test->death_test; > > + spin_unlock_irqrestore(&test->lock, flags); > > + > > + return death_test; > > +} > > + > > +static void kunit_set_death_test(struct kunit *test, bool death_test) > > +{ > > + unsigned long flags; > > + > > + spin_lock_irqsave(&test->lock, flags); > > + test->death_test = death_test; > > + spin_unlock_irqrestore(&test->lock, flags); > > +} > > + > > static int kunit_vprintk_emit(const struct kunit *test, > > int level, > > const char *fmt, > > @@ -70,13 +91,29 @@ static void kunit_fail(struct kunit *test, struct kunit_stream *stream) > > stream->commit(stream); > > } > > > > +static void __noreturn kunit_abort(struct kunit *test) > > +{ > > + kunit_set_death_test(test, true); > > + > > + test->try_catch.throw(&test->try_catch); > > + > > + /* > > + * Throw could not abort from test. > > + */ > > + kunit_err(test, "Throw could not abort from test!"); > > + show_stack(NULL, NULL); > > + BUG(); > > kunit_abort() is what will be call as the result of an assert failure. Yep. Does that need clarified somewhere? > > BUG(), which is a panic, which is crashing the system is not acceptable > in the Linux kernel. You will just annoy Linus if you submit this. Sorry, I thought this was an acceptable use case since, a) this should never be compiled in a production kernel, b) we are in a pretty bad, unpredictable state if we get here and keep going. I think you might have said elsewhere that you think "a" is not valid? In any case, I can replace this with a WARN, would that be acceptable?