| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20190813003352.GA235915@google.com>
Date: Mon, 12 Aug 2019 17:33:52 -0700
From: Brendan Higgins <brendanhiggins@...gle.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: frowand.list@...il.com, gregkh@...uxfoundation.org,
jpoimboe@...hat.com, keescook@...gle.com,
kieran.bingham@...asonboard.com, mcgrof@...nel.org,
peterz@...radead.org, robh@...nel.org, shuah@...nel.org,
tytso@....edu, yamada.masahiro@...ionext.com,
devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
kunit-dev@...glegroups.com, linux-doc@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-nvdimm@...ts.01.org, linux-um@...ts.infradead.org,
Alexander.Levin@...rosoft.com, Tim.Bird@...y.com,
amir73il@...il.com, dan.carpenter@...cle.com, daniel@...ll.ch,
jdike@...toit.com, joel@....id.au, julia.lawall@...6.fr,
khilman@...libre.com, knut.omang@...cle.com, logang@...tatee.com,
mpe@...erman.id.au, pmladek@...e.com, rdunlap@...radead.org,
richard@....at, rientjes@...gle.com, rostedt@...dmis.org,
wfg@...ux.intel.com
Subject: Re: [PATCH v12 05/18] kunit: test: add the concept of expectations
On Mon, Aug 12, 2019 at 04:57:00PM -0700, Stephen Boyd wrote:
> Quoting Brendan Higgins (2019-08-12 11:24:08)
> > Add support for expectations, which allow properties to be specified and
> > then verified in tests.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@...gle.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@...tatee.com>
>
> Reviewed-by: Stephen Boyd <sboyd@...nel.org>
>
> Just some minor nits again.
>
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > index d0bf112910caf..2625bcfeb19ac 100644
> > --- a/include/kunit/test.h
> > +++ b/include/kunit/test.h
> > @@ -9,8 +9,10 @@
> > #ifndef _KUNIT_TEST_H
> > #define _KUNIT_TEST_H
> >
> > +#include <linux/kernel.h>
> > #include <linux/types.h>
> > #include <linux/slab.h>
> > +#include <kunit/assert.h>
>
> Can you alphabet sort these?
Sure. Will fix.
> >
> > struct kunit_resource;
> >
> > @@ -319,4 +321,845 @@ void __printf(3, 4) kunit_printk(const char *level,
> > #define kunit_err(test, fmt, ...) \
> > kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
> >
> > +/*
> > + * Generates a compile-time warning in case of comparing incompatible types.
> > + */
> > +#define __kunit_typecheck(lhs, rhs) \
> > + ((void) __typecheck(lhs, rhs))
>
> Is there a reason why this can't be inlined and the __kunit_typecheck()
> macro can't be removed?
No real reason anymore. I used it in multiple places before and we
weren't sure if we wanted to stick with the warnings that __typecheck
produces long term, but now that it is only used in one place, I guess
that doesn't make sense anymore. Will fix.
> > +
> > +/**
> > + * KUNIT_SUCCEED() - A no-op expectation. Only exists for code clarity.
> > + * @test: The test context object.
> [...]
> > + * @condition: an arbitrary boolean expression. The test fails when this does
> > + * not evaluate to true.
> > + *
> > + * This and expectations of the form `KUNIT_EXPECT_*` will cause the test case
> > + * to fail when the specified condition is not met; however, it will not prevent
> > + * the test case from continuing to run; this is otherwise known as an
> > + * *expectation failure*.
> > + */
> > +#define KUNIT_EXPECT_TRUE(test, condition) \
> > + KUNIT_TRUE_ASSERTION(test, KUNIT_EXPECTATION, condition)
>
> A lot of these macros seem double indented.
In a case you pointed out in the preceding patch, I was just keeping the
arguments column aligned.
In this case I am just indenting two tabs for a line continuation. I
thought I found other instances in the kernel that did this early on
(and that's also what the Linux kernel vim plugin wanted me to do).
After a couple of spot checks, it seems like one tab for this kind of
line continuation seems more common. I personally don't feel strongly
about any particular version. I just want to know now what the correct
indentation is for macros before I go through and change them all.
I think there are three cases:
#define macro0(param0, param1) \
a_really_long_macro(...)
In this first case, I use two tabs for the first indent, I think you are
telling me this should be one tab.
#define macro1(param0, param1) { \
statement_in_a_block0; \
statement_in_a_block1; \
... \
}
In this case, every line is in a block and is indented as it would be in
a function body. I think you are okay with this, and now that I am
thinking about it, what I think you are proposing for macro0 will make
these two cases more consistent.
#define macro2(param0, \
param1, \
param2, \
param3, \
..., \
paramn) ... \
In this last case, the body would be indented as in macro0, or macro1,
but the parameters passed into the macro are column aligned, consistent
with one of the acceptable ways of formatting function parameters that
don't fit on a single line.
In all cases, I put 1 space in between the closing parameter paren and
the line continuation `\`, if only one `\` is needed. Otherwise, I align
all the `\s` to the 80th column. Is this okay, or would you prefer that
I align them all to the 80th column, or something else?
> > +
> > +#define KUNIT_EXPECT_TRUE_MSG(test, condition, fmt, ...) \
> > + KUNIT_TRUE_MSG_ASSERTION(test, \
> > + KUNIT_EXPECTATION, \
> > + condition, \
> > + fmt, \
> > + ##__VA_ARGS__)
> > +
Powered by blists - more mailing lists