[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGS_qxqJeMDXA1b_MJrHSg8rGEM6K2UXqaxNVmwW_oQEFwQ1Xw@mail.gmail.com>
Date: Fri, 26 May 2023 11:52:05 -0700
From: Daniel Latypov <dlatypov@...gle.com>
To: David Gow <davidgow@...gle.com>
Cc: Dan Carpenter <dan.carpenter@...aro.org>,
Shuah Khan <skhan@...uxfoundation.org>,
Brendan Higgins <brendan.higgins@...ux.dev>,
Rae Moar <rmoar@...gle.com>, kunit-dev@...glegroups.com,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] kunit: Move kunit_abort() call out of kunit_do_failed_assertion()
On Fri, May 26, 2023 at 12:54 AM David Gow <davidgow@...gle.com> wrote:
>
> KUnit aborts the current thread when an assertion fails. Currently, this
> is done conditionally as part of the kunit_do_failed_assertion()
> function, but this hides the kunit_abort() call from the compiler
> (particularly if it's in another module). This, in turn, can lead to
> both suboptimal code generation (the compiler can't know if
> kunit_do_failed_assertion() will return), and to static analysis tools
> like smatch giving false positives.
Another thought: this impacts
https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/kunit.rs.
They're currently calling kunit_do_failed_assert() always with type=ASSERTION.
This change would actually make things better since they could handle
shutting down the thread themselves instead of having it happen behind
an opaque FFI layer.
But we'd just need to make sure we get that code updated around when
this change goes in.
Daniel
Powered by blists - more mailing lists