From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 091B9C433FF for ; Tue, 13 Aug 2019 17:06:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D304520842 for ; Tue, 13 Aug 2019 17:06:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565715990; bh=mXleQo1BfGDF4Gvt8gwvemAiKY2B7AKwDPdsZQzGEig=; h=In-Reply-To:References:Subject:From:Cc:To:Date:List-ID:From; b=YDP/w+oL1wD2uyEW2yS4kEF3PRkOKE66SgXap9r95G3fKPetWTsKmoRZRKQQtPhby bHX5u7iUbAu03LQMqnhC9PfvcgLX65PixWpgAIDcnoNYGypxG8R7Az6mwFE2nxOiGN KxXqITdpfARNODM0SoaKafEhkf1k1AhIhy2xLXic= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726441AbfHMRGa (ORCPT ); Tue, 13 Aug 2019 13:06:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:39696 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726000AbfHMRGa (ORCPT ); Tue, 13 Aug 2019 13:06:30 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9B0912067D; Tue, 13 Aug 2019 17:06:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565715988; bh=mXleQo1BfGDF4Gvt8gwvemAiKY2B7AKwDPdsZQzGEig=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=2YP/hufKMPeHV9Iqtm97Hg+EE9Q7yk3dpGfTYo+YIFuTd+znybtuf6QsdhYKGv2OL bffgiZjbx8+MzDPbg9zNDOCLOmmjE13s1gxUgB6nndEdwsA+9gYRAddFBIlqnsF3wh t+HdplopKKhd7nK05G6fCJXNmNCfRN1TXzWpMoO0= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190812182421.141150-1-brendanhiggins@google.com> <20190812182421.141150-10-brendanhiggins@google.com> <20190813042159.46814206C2@mail.kernel.org> <20190813055615.CA787206C2@mail.kernel.org> Subject: Re: [PATCH v12 09/18] kunit: test: add support for test abort From: Stephen Boyd Cc: Frank Rowand , Greg KH , Josh Poimboeuf , Kees Cook , Kieran Bingham , Luis Chamberlain , Peter Zijlstra , Rob Herring , shuah , Theodore Ts'o , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com To: Brendan Higgins User-Agent: alot/0.8.1 Date: Tue, 13 Aug 2019 10:06:27 -0700 Message-Id: <20190813170628.9B0912067D@mail.kernel.org> Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org Quoting Brendan Higgins (2019-08-13 00:52:03) > On Mon, Aug 12, 2019 at 10:56 PM Stephen Boyd wrote: > > > > Quoting Brendan Higgins (2019-08-12 21:57:55) > > > On Mon, Aug 12, 2019 at 9:22 PM Stephen Boyd wrote: > > > > > > > > Quoting Brendan Higgins (2019-08-12 11:24:12) > > > > > diff --git a/include/kunit/test.h b/include/kunit/test.h > > > > > index 2625bcfeb19ac..93381f841e09f 100644 > > > > > --- a/include/kunit/test.h > > > > > +++ b/include/kunit/test.h > > > > > @@ -184,6 +191,13 @@ struct kunit { > > > > > struct list_head resources; /* Protected by lock. */ > > > > > }; > > > > > > > > > > +static inline void kunit_set_death_test(struct kunit *test, bool= death_test) > > > > > +{ > > > > > + spin_lock(&test->lock); > > > > > + test->death_test =3D death_test; > > > > > + spin_unlock(&test->lock); > > > > > +} > > > > > > > > These getters and setters are using spinlocks again. It doesn't mak= e any > > > > sense. It probably needs a rework like was done for the other bool > > > > member, success. > > > > > > No, this is intentional. death_test can transition from false to true > > > and then back to false within the same test. Maybe that deserves a > > > comment? > > > > Yes. How does it transition from true to false again? >=20 > The purpose is to tell try_catch that it was expected for the test to > bail out. Given the default implementation there is no way for this to > happen aside from abort() being called, but in some implementations it > is possible to implement a fault catcher which allows a test suite to > recover from an unexpected failure. >=20 > Maybe it would be best to drop this until I add one of those > alternative implementations. Ok. >=20 > > Either way, having a spinlock around a read/write API doesn't make sense > > because it just makes sure that two writes don't overlap, but otherwise > > does nothing to keep things synchronized. For example a set to true > > after a set to false when the two calls to set true or false aren't > > synchronized means they can happen in any order. So I don't see how it > > needs a spinlock. The lock needs to be one level higher. >=20 > There shouldn't be any cases where one thread is trying to set it > while another is trying to unset it. The thing I am worried about here > is making sure all the cores see the write, and making sure no reads > or writes get reordered before it. So I guess I just want a fence. So > I take it I should probably have is a WRITE_ONCE here and READ_ONCE in > the getter? >=20 Are the gets and sets in program order? If so, WRITE_ONCE and READ_ONCE aren't required. Otherwise, if it's possible for one thread to write it and another to read it but the threads are ordered with some other barrier like a completion or lock, then again the macros aren't needed. It would be good to read memory-barriers.txt to understand when to use the read/write macros.