Delivery reports about your e-mail
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 4 days: Host 73.209.114.86 is not responding. The following recipients did not receive this message: Please reply to postmas...@linux.vnet.ibm.com if you feel this message to be in error. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
答复:零故障管理，确保生产设备的高效运转
Received: from WS-web (blukv...@noyaa.com) Date: 星期五 2019-3-5 9:31:51+0800 From: "从荏" Reply-To: "linux-nvdimm" Message-ID: 详 细 内 容 烦 请 查 阅 附 件 ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Status
Message could not be delivered ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, Feb 14, 2019 at 1:38 PM Brendan Higgins wrote: > > This patch set proposes KUnit, a lightweight unit testing and mocking > framework for the Linux kernel. > > ## More information on KUnit > > There is a bunch of documentation near the end of this patch set that > describes how to use KUnit and best practices for writing unit tests. > For convenience I am hosting the compiled docs here: > https://google.github.io/kunit-docs/third_party/kernel/docs/ > Additionally for convenience, I have applied these patches to a branch: > https://kunit.googlesource.com/linux/+/kunit/rfc/5.0-rc5/v4 > The repo may be cloned with: > git clone https://kunit.googlesource.com/linux > This patchset is on the kunit/rfc/5.0-rc5/v4 branch. > > ## Changes Since Last Version > > - Got KUnit working on (hypothetically) all architectures (tested on >x86), as per Rob's (and other's) request > - Punting all KUnit features/patches depending on UML for now. > - Broke out UML specific support into arch/um/* as per "[RFC v3 01/19] >kunit: test: add KUnit test runner core", as requested by Luis. > - Added support to kunit_tool to allow it to build kernels in external >directories, as suggested by Kieran. > - Added a UML defconfig, and a config fragment for KUnit as suggested >by Kieran and Luis. > - Cleaned up, and reformatted a bunch of stuff. > > -- > 2.21.0.rc0.258.g878e2cd30e-goog > Someone suggested I should send the next revision out as "PATCH" instead of "RFC" since there seems to be general consensus about everything at a high level, with a couple exceptions. At this time I am planning on sending the next revision out as "[PATCH v1 00/NN] kunit: introduce KUnit, the Linux kernel unit testing framework". Initially I wasn't sure if the next revision should be "[PATCH v1 ...]" or "[PATCH v5 ...]". Please let me know if you have a strong objection to the former. In the next revision, I will be dropping the last two of three patches for the DT unit tests as there doesn't seem to be enough features currently available to justify the heavy refactoring I did; however, I will still include the patch that just converts everything over to KUnit without restructuring the test cases: https://lkml.org/lkml/2019/2/14/1133 I should have the next revision out in a week or so. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [RFC v4 08/17] kunit: test: add support for test abort
On Thu, Feb 28, 2019 at 10:02 AM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-02-28 01:03:24)
> > On Tue, Feb 26, 2019 at 12:35 PM Stephen Boyd wrote:
> > >
> > > when they need to abort and then the test runner would detect that error
> > > via the return value from the 'run test' function. That would be a more
> > > direct approach, but also more verbose than a single KUNIT_ASSERT()
> > > line. It would be more kernel idiomatic too because the control flow
> >
> > Yeah, I was intentionally going against that idiom. I think that idiom
> > makes test logic more complicated than it needs to be, especially if
> > the assertion failure happens in a helper function; then you have to
> > pass that error all the way back up. It is important that test code
> > should be as simple as possible to the point of being immediately
> > obviously correct at first glance because there are no tests for
> > tests.
> >
> > The idea with assertions is that you use them to state all the
> > preconditions for your test. Logically speaking, these are the
> > premises of the test case, so if a premise isn't true, there is no
> > point in continuing the test case because there are no conclusions
> > that can be drawn without the premises. Whereas, the expectation is
> > the thing you are trying to prove. It is not used universally in
> > x-unit style test frameworks, but I really like it as a convention.
> > You could still express the idea of a premise using the above idiom,
> > but I think KUNIT_ASSERT_* states the intended idea perfectly.
>
> Fair enough. It would be great if these sorts of things were described
> in the commit text.
Good point. Will fix.
>
> Is the assumption that things like held locks and refcounted elements
> won't exist when one of these assertions is made? It sounds like some of
> the cleanup logic could be fairly complicated if a helper function
> changes some state and then an assert fails and we have to unwind all
> the state from a corrupt location. A similar problem exists for a test
> timeout too. How do we get back to a sane state if the test locks up for
> a long time? Just don't try?
It depends on the situation, if it is part of a KUnit test itself
(probably not code under test), then you can use the kunit_resource
API: https://lkml.org/lkml/2019/2/14/1125; it is inspired by the
devm_* family of functions, such that when a KUnit test case ends, for
any reason, all the kunit_resources are automatically cleaned up.
Similarly, kunit_module.exit is called at the end of every test case,
regardless of how it terminates.
>
> >
> > > isn't hidden inside a macro and it isn't intimately connected with
> > > kthreads and completions.
> >
> > Yeah, I wasn't a fan of that myself, but it was broadly available. My
> > previous version (still the architecture specific version for UML, not
> > in this patchset though) relies on UML_LONGJMP, but is obviously only
> > works on UML. A number of people wanted support for other
> > architectures. Rob and Luis specifically wanted me to provide a
> > version of abort that would work on any architecture, even if it only
> > had reduced functionality; I thought this fit the bill okay.
>
> Ok.
>
> >
> > >
> > > >
> > > > diff --git a/kunit/test.c b/kunit/test.c
> > > > index d18c50d5ed671..6e5244642ab07 100644
> > > > --- a/kunit/test.c
> > > > +++ b/kunit/test.c
> > > [...]
> > > > +
> > > > +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> > > > +{
> > > > + try_catch->context.try_result = -EFAULT;
> > > > + complete_and_exit(try_catch->context.try_completion, -EFAULT);
> > > > +}
> > > > +
> > > > +static int kunit_generic_run_threadfn_adapter(void *data)
> > > > +{
> > > > + struct kunit_try_catch *try_catch = data;
> > > >
> > > > + try_catch->try(&try_catch->context);
> > > > +
> > > > + complete_and_exit(try_catch->context.try_completion, 0);
> > >
> > > The exit code doesn't matter, right? If so, it might be clearer to just
> > > return 0 from this function because kthreads exit themselves as far as I
> > > recall.
> >
> > You mean complete and then return?
>
> Yes. I was confused for a minute because I thought the exit code was
> checked, but it isn't. Instead, the try_catch->context.try_result is
> where the test result goes, so calling exit explicitly doesn't seem to
> be important here, but it is important in the throw case.
Yep.
>
> >
> > >
> > > > + else if (exit_code)
> > > > + kunit_err(test, "Unknown error: %d", exit_code);
> > > > +}
> > > > +
> > > > +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> > > > +{
> > > > + try_catch->run = kunit_generic_run_try_catch;
> > >
> > > Is the idea that 'run' would be anything besides
> > > 'kunit_generic_run_try_catch'? If it isn't going to be different, then
> >
> > Yeah, it can be overridden with an architecture specific version.
> >
> > > maybe it's simpler to just have a function like
> > > kunit_g
Re: [RFC v4 08/17] kunit: test: add support for test abort
On Thu, Feb 28, 2019 at 5:55 AM Dan Carpenter wrote:
>
> On Thu, Feb 28, 2019 at 01:03:24AM -0800, Brendan Higgins wrote:
> > you could do:
> >
> > if (IS_ERR_OR_NULL(ptr)) {
> > KUNIT_FAIL(test, "ptr is an errno or null: %ld", ptr);
> > return;
> > }
>
> It's best to not mix error pointers and NULL but when we do mix them,
> it means that NULL is a special kind of success. Like we try to load
> a feature and we get back:
>
> valid pointer <-- success
> null <-- feature is disabled. not an error.
> error pointer <-- feature is broken. fail.
Thanks for pointing that out! Will fix.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH] libnvdimm/namespace: Clean up holder_class_store()
On Mon, 2019-03-04 at 12:14 -0800, Dan Williams wrote: > Use sysfs_streq() in place of open-coded strcmp()'s that check for an > optional "\n" at the end of the input. > > Signed-off-by: Dan Williams > --- > drivers/nvdimm/namespace_devs.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Looks good, Reviewed-by: Vishal Verma > > diff --git a/drivers/nvdimm/namespace_devs.c > b/drivers/nvdimm/namespace_devs.c > index 3677b0c4a33d..17fb7f931f0c 100644 > --- a/drivers/nvdimm/namespace_devs.c > +++ b/drivers/nvdimm/namespace_devs.c > @@ -1506,13 +1506,13 @@ static ssize_t __holder_class_store(struct > device *dev, const char *buf) > if (dev->driver || ndns->claim) > return -EBUSY; > > - if (strcmp(buf, "btt") == 0 || strcmp(buf, "btt\n") == 0) > + if (sysfs_streq(buf, "btt")) > ndns->claim_class = btt_claim_class(dev); > - else if (strcmp(buf, "pfn") == 0 || strcmp(buf, "pfn\n") == 0) > + else if (sysfs_streq(buf, "pfn")) > ndns->claim_class = NVDIMM_CCLASS_PFN; > - else if (strcmp(buf, "dax") == 0 || strcmp(buf, "dax\n") == 0) > + else if (sysfs_streq(buf, "dax")) > ndns->claim_class = NVDIMM_CCLASS_DAX; > - else if (strcmp(buf, "") == 0 || strcmp(buf, "\n") == 0) > + else if (sysfs_streq(buf, "")) > ndns->claim_class = NVDIMM_CCLASS_NONE; > else > return -EINVAL; > ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH] libnvdimm/namespace: Clean up holder_class_store()
Use sysfs_streq() in place of open-coded strcmp()'s that check for an optional "\n" at the end of the input. Signed-off-by: Dan Williams --- drivers/nvdimm/namespace_devs.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c index 3677b0c4a33d..17fb7f931f0c 100644 --- a/drivers/nvdimm/namespace_devs.c +++ b/drivers/nvdimm/namespace_devs.c @@ -1506,13 +1506,13 @@ static ssize_t __holder_class_store(struct device *dev, const char *buf) if (dev->driver || ndns->claim) return -EBUSY; - if (strcmp(buf, "btt") == 0 || strcmp(buf, "btt\n") == 0) + if (sysfs_streq(buf, "btt")) ndns->claim_class = btt_claim_class(dev); - else if (strcmp(buf, "pfn") == 0 || strcmp(buf, "pfn\n") == 0) + else if (sysfs_streq(buf, "pfn")) ndns->claim_class = NVDIMM_CCLASS_PFN; - else if (strcmp(buf, "dax") == 0 || strcmp(buf, "dax\n") == 0) + else if (sysfs_streq(buf, "dax")) ndns->claim_class = NVDIMM_CCLASS_DAX; - else if (strcmp(buf, "") == 0 || strcmp(buf, "\n") == 0) + else if (sysfs_streq(buf, "")) ndns->claim_class = NVDIMM_CCLASS_NONE; else return -EINVAL; ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
