From: Alan Maguire <alan.maguire@oracle.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Brendan Higgins <brendanhiggins@google.com>,
Matthias Maennich <maennich@google.com>,
shuah@kernel.org, john.johansen@canonical.com, jmorris@namei.org,
serge@hallyn.com, keescook@chromium.org, alan.maguire@oracle.com,
yzaikin@google.com, davidgow@google.com, tytso@mit.edu,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org,
Mike Salvatore <mike.salvatore@canonical.com>
Subject: Re: [PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit tests for policy unpack
Date: Sat, 19 Oct 2019 13:56:01 +0100 (BST) [thread overview]
Message-ID: <alpine.LRH.2.20.1910191348280.11804@dhcp-10-175-221-34.vpn.oracle.com> (raw)
In-Reply-To: <20191018122949.GD11244@42.do-not-panic.com>
On Fri, 18 Oct 2019, Luis Chamberlain wrote:
> On Thu, Oct 17, 2019 at 05:18:16PM -0700, Brendan Higgins wrote:
> > From: Mike Salvatore <mike.salvatore@canonical.com>
> >
> > In order to write the tests against the policy unpacking code, some
> > static functions needed to be exposed for testing purposes. One of the
> > goals of this patch is to establish a pattern for which testing these
> > kinds of functions should be done in the future.
>
> And you'd run into the same situation expressed elsewhere with kunit of
> an issue of the kunit test as built-in working but if built as a module
> then it would not work, given the lack of exports. Symbols namespaces
> should resolve this [0], and we'd be careful where a driver imports this
> namespace.
>
> [0] https://lwn.net/Articles/798254/
>
Thanks for the link! Looks interesting for us definitely!
WRT adding tests, I think what we're aiming at is a set of best practices
to advise test developers using KUnit, while attempting to minimize
side-effects of any changes we need to make to support testability.
One aspect of this we probably have to consider is inlining of code. For
cases like this where the functions are small and are called in a small
number of cases, any testability changes we make may push a
previously-inlined function to not be inlined, with potential performance
side-effects for the subsystem. In such cases, I wonder if the right
answer would be to suggest actually defining the functions as
inline in the header file? That way the compiler still gets to decide (as
opposed to __always_inline), and we don't perturb performance too much.
Thanks!
Alan
> Luis
>
next prev parent reply other threads:[~2019-10-19 12:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 0:18 [PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit tests for policy unpack Brendan Higgins
2019-10-18 0:33 ` Iurii Zaikin
2019-10-30 18:59 ` Kees Cook
2019-11-06 0:35 ` Brendan Higgins
2019-11-06 0:37 ` Brendan Higgins
2019-10-18 0:43 ` Brendan Higgins
2019-10-18 16:25 ` Theodore Y. Ts'o
2019-10-18 21:41 ` Brendan Higgins
2019-10-30 19:02 ` Kees Cook
2019-10-31 9:01 ` Brendan Higgins
2019-10-18 12:29 ` Luis Chamberlain
2019-10-19 12:56 ` Alan Maguire [this message]
2019-10-19 18:36 ` Luis Chamberlain
2019-10-24 0:42 ` Brendan Higgins
2019-10-24 10:15 ` Luis Chamberlain
2019-10-30 19:09 ` Kees Cook
2019-10-30 20:11 ` Iurii Zaikin
2019-10-31 1:40 ` John Johansen
2019-10-31 9:33 ` Brendan Higgins
2019-10-31 18:40 ` Kees Cook
2019-11-05 16:43 ` Mike Salvatore
2019-11-05 23:59 ` Brendan Higgins
2019-10-31 1:37 ` John Johansen
2019-10-31 9:17 ` Brendan Higgins
2019-11-01 12:30 ` Alan Maguire
2019-11-05 23:44 ` Brendan Higgins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.20.1910191348280.11804@dhcp-10-175-221-34.vpn.oracle.com \
--to=alan.maguire@oracle.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=maennich@google.com \
--cc=mcgrof@kernel.org \
--cc=mike.salvatore@canonical.com \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=tytso@mit.edu \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).