* Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
From: Wim Van Sebroeck @ 2019-06-15 10:02 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Guenter Roeck, linux-watchdog@vger.kernel.org, Wim Van Sebroeck,
Jonathan Corbet, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Esben Haabendal, Jerry Hoemann,
Rasmus Villemoes
In-Reply-To: <56280052-9437-9813-a24e-125abb876762@prevas.dk>
Hi Rasmus,
> > On Wed, Jun 05, 2019 at 02:06:44PM +0000, Rasmus Villemoes wrote:
> >> When the watchdog device is not open by userspace, the kernel takes
> >> care of pinging it. When the open_timeout feature is in use, we should
> >> ensure that the hardware fires close to open_timeout seconds after the
> >> kernel has assumed responsibility for the device.
> >>
> >> To do this, simply reuse the logic that is already in place for
> >> ensuring the same thing when userspace is responsible for regularly
> >> pinging the device:
> >>
> >> - When watchdog_active(wdd), this patch doesn't change anything.
> >>
> >> - When !watchdoc_active(wdd), the "virtual timeout" should be taken to
> >
> > s/watchdoc_active/watchdog_active/
> >
> > otherwise
> >
> > Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Thanks! Wim, can you fix up if/when applying, or do you prefer I resend?
I'll fix up when applying. No need to resend a new patch for that.
Kind regards,
Wim.
^ permalink raw reply
* Re: [PATCH 14/14] docs: sphinx/kernel_abi.py: fix UTF-8 support
From: Greg Kroah-Hartman @ 2019-06-15 6:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190614132530.7a013757@coco.lan>
On Fri, Jun 14, 2019 at 01:25:30PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 14 Jun 2019 18:18:37 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Thu, Jun 13, 2019 at 11:04:20PM -0300, Mauro Carvalho Chehab wrote:
> > > The parser breaks with UTF-8 characters with Sphinx 1.4.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > ---
> > > Documentation/sphinx/kernel_abi.py | 10 ++++++----
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
> > > index 7fa7806532dc..460cee48a245 100644
> > > --- a/Documentation/sphinx/kernel_abi.py
> > > +++ b/Documentation/sphinx/kernel_abi.py
> > > @@ -1,4 +1,5 @@
> > > -# -*- coding: utf-8; mode: python -*-
> > > +# coding=utf-8
> > > +#
> >
> > Is this an emacs vs. vim fight?
>
> No. This is a python-specific thing:
>
> https://www.python.org/dev/peps/pep-0263/
Ah, thanks, didn't know that.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 00/16] Add support to generate ABI documentation at admin-guide
From: Greg Kroah-Hartman @ 2019-06-15 6:15 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Rajat Jain, Bjorn Helgaas
In-Reply-To: <20190614150736.043cb2dd@coco.lan>
On Fri, Jun 14, 2019 at 03:07:36PM -0300, Mauro Carvalho Chehab wrote:
> Greg,
>
> In time: forgot to add a 00/16 patch... someone come to my desk while I was
> sending this... sorry for that.
>
> That's the second version of the doc ABI updated logic.
>
> Changes from version 1:
>
> - I updated my e-mail on older patches;
>
> - Two new ABI fix patches;
Both abi fix patches now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v4 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-06-14 23:22 UTC (permalink / raw)
To: 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, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, 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
In-Reply-To: <20190517185304.24EBE20848@mail.kernel.org>
On Fri, May 17, 2019 at 11:53 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:54)
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > new file mode 100644
> > index 0000000000000..e682ea0e1f9a5
> > --- /dev/null
> > +++ b/include/kunit/test.h
> > @@ -0,0 +1,162 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Base unit test (KUnit) API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins@google.com>
> > + */
> > +
> > +#ifndef _KUNIT_TEST_H
> > +#define _KUNIT_TEST_H
> > +
> > +#include <linux/types.h>
> > +#include <linux/slab.h>
>
> Is this include used here?
Err, it is used in the very next commit in the sequence. Sorry, I will
add it in the commit that actually uses it in the next revision.
> > +
> > +struct kunit;
> > +
> > +/**
> > + * struct kunit_case - represents an individual test case.
> > + * @run_case: the function representing the actual test case.
> > + * @name: the name of the test case.
> > + *
> > + * A test case is a function with the signature, ``void (*)(struct kunit *)``
> > + * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. Each
> > + * test case is associated with a &struct kunit_module and will be run after the
> > + * module's init function and followed by the module's exit function.
> > + *
> > + * A test case should be static and should only be created with the KUNIT_CASE()
> > + * macro; additionally, every array of test cases should be terminated with an
> > + * empty test case.
> > + *
> > + * Example:
> > + *
> > + * .. code-block:: c
> > + *
> > + * void add_test_basic(struct kunit *test)
> > + * {
> > + * KUNIT_EXPECT_EQ(test, 1, add(1, 0));
> > + * KUNIT_EXPECT_EQ(test, 2, add(1, 1));
> > + * KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
> > + * KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
> > + * KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
> > + * }
> > + *
> > + * static struct kunit_case example_test_cases[] = {
> > + * KUNIT_CASE(add_test_basic),
> > + * {},
>
> Nitpick: Please drop the comma on the sentinel so nobody gets ideas to
> add another entry after it.
Good idea. Will fix here and elsewhere.
> > + * };
> > + *
> > + */
> > +struct kunit_case {
> > + void (*run_case)(struct kunit *test);
> > + const char name[256];
>
> Maybe 256 can be a #define KUNIT_NAME_MAX_LEN? Or it could just be a
> const char pointer to a literal pool? Are unit tests making up names at
> runtime?
Yeah, sorry, I forgot why I did it this way in the first place. Will
fix in next revision.
> > +
> > + /* private: internal use only. */
> > + bool success;
> > +};
> > +
> > +/**
> > + * KUNIT_CASE - A helper for creating a &struct kunit_case
> > + * @test_name: a reference to a test case function.
> > + *
> > + * Takes a symbol for a function representing a test case and creates a
> > + * &struct kunit_case object from it. See the documentation for
> > + * &struct kunit_case for an example on how to use it.
> > + */
> > +#define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
> > +
> > +/**
> > + * struct kunit_module - describes a related collection of &struct kunit_case s.
> > + * @name: the name of the test. Purely informational.
> > + * @init: called before every test case.
> > + * @exit: called after every test case.
> > + * @test_cases: a null terminated array of test cases.
> > + *
> > + * A kunit_module is a collection of related &struct kunit_case s, such that
> > + * @init is called before every test case and @exit is called after every test
> > + * case, similar to the notion of a *test fixture* or a *test class* in other
> > + * unit testing frameworks like JUnit or Googletest.
> > + *
> > + * Every &struct kunit_case must be associated with a kunit_module for KUnit to
> > + * run it.
> > + */
> > +struct kunit_module {
> > + const char name[256];
> > + int (*init)(struct kunit *test);
> > + void (*exit)(struct kunit *test);
> > + struct kunit_case *test_cases;
>
> Can this variable be const? Or we expect test modules to adjust test_cases after
> the fact?
I understand why it would be nice to do it that way, but we store the
failed result on test cases; I don't think it really makes sense to
have another parallel data structure just for the results on each test
case.
> > +};
> > +
> > +/**
> > + * struct kunit - represents a running instance of a test.
> > + * @priv: for user to store arbitrary data. Commonly used to pass data created
> > + * in the init function (see &struct kunit_module).
> > + *
> > + * Used to store information about the current context under which the test is
> > + * running. Most of this data is private and should only be accessed indirectly
> > + * via public functions; the one exception is @priv which can be used by the
> > + * test writer to store arbitrary data.
> > + */
> > +struct kunit {
> > + void *priv;
> > +
> > + /* private: internal use only. */
> > + const char *name; /* Read only after initialization! */
> > + spinlock_t lock; /* Gaurds all mutable test state. */
> > + bool success; /* Protected by lock. */
> > +};
> > +
> > +void kunit_init_test(struct kunit *test, const char *name);
> > +
> > +int kunit_run_tests(struct kunit_module *module);
> > +
> > +/**
> > + * module_test() - used to register a &struct kunit_module with KUnit.
> > + * @module: a statically allocated &struct kunit_module.
> > + *
> > + * Registers @module with the test framework. See &struct kunit_module for more
> > + * information.
> > + */
> > +#define module_test(module) \
> > + static int module_kunit_init##module(void) \
> > + { \
> > + return kunit_run_tests(&module); \
> > + } \
> > + late_initcall(module_kunit_init##module)
>
> Maybe we need to introduce another initcall level after
> late_initcall_sync() for tests? I wonder if there will be tests that
> need to run after all other initcalls have run, including late sync
> initcalls.
Yeah, I have another patch ready to go to do that. I guess I just
figured that was something that could lead to a lot of bikeshedding
that I wanted to avoid in the initial patchset.
Nevertheless, I can add it in if you feel it is better to discuss now.
> > +
> > +void __printf(3, 4) kunit_printk(const char *level,
> > + const struct kunit *test,
> > + const char *fmt, ...);
> > +
> > +/**
> > + * kunit_info() - Prints an INFO level message associated with the current test.
> > + * @test: The test context object.
> > + * @fmt: A printk() style format string.
> > + *
> > + * Prints an info level message associated with the test module being run. Takes
> > + * a variable number of format parameters just like printk().
> > + */
> > +#define kunit_info(test, fmt, ...) \
> > + kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
> > +
> > +/**
> > + * kunit_warn() - Prints a WARN level message associated with the current test.
> > + * @test: The test context object.
> > + * @fmt: A printk() style format string.
> > + *
> > + * See kunit_info().
>
> Why? Just write out that it "Prints a warning level message".
>
> > + */
> > +#define kunit_warn(test, fmt, ...) \
> > + kunit_printk(KERN_WARNING, test, fmt, ##__VA_ARGS__)
> > +
> > +/**
> > + * kunit_err() - Prints an ERROR level message associated with the current test.
> > + * @test: The test context object.
> > + * @fmt: A printk() style format string.
> > + *
> > + * See kunit_info().
>
> Same comment.
>
> > + */
> > +#define kunit_err(test, fmt, ...) \
> > + kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
> > +
> > +#endif /* _KUNIT_TEST_H */
> > diff --git a/kunit/Kconfig b/kunit/Kconfig
> > new file mode 100644
> > index 0000000000000..64480092b2c24
> > --- /dev/null
> > +++ b/kunit/Kconfig
> > @@ -0,0 +1,16 @@
> > +#
> > +# KUnit base configuration
> > +#
> > +
> > +menu "KUnit support"
> > +
> > +config KUNIT
> > + bool "Enable support for unit tests (KUnit)"
> > + help
> > + Enables support for kernel unit tests (KUnit), a lightweight unit
> > + testing and mocking framework for the Linux kernel. These tests are
> > + able to be run locally on a developer's workstation without a VM or
> > + special hardware. For more information, please see
> > + Documentation/kunit/
>
> This moved and needs an update.
>
> > +
> > +endmenu
> > diff --git a/kunit/Makefile b/kunit/Makefile
> > new file mode 100644
> > index 0000000000000..5efdc4dea2c08
> > --- /dev/null
> > +++ b/kunit/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_KUNIT) += test.o
> > diff --git a/kunit/test.c b/kunit/test.c
> > new file mode 100644
> > index 0000000000000..86f65ba2bcf92
> > --- /dev/null
> > +++ b/kunit/test.c
> > @@ -0,0 +1,229 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Base unit test (KUnit) API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins@google.com>
> > + */
> > +
> > +#include <linux/sched.h>
>
> This include gets removed later in the series, was it ever needed?
Nope, that was a mistake. Sorry.
> > +#include <linux/sched/debug.h>
> > +#include <kunit/test.h>
> > +
> > +static bool kunit_get_success(struct kunit *test)
> > +{
> > + unsigned long flags;
> > + bool success;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
> > + success = test->success;
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +
> > + return success;
> > +}
> > +
> > +static void kunit_set_success(struct kunit *test, bool success)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
> > + test->success = success;
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +}
> > +
> > +static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
> > +{
> > + return vprintk_emit(0, level, NULL, 0, fmt, args);
> > +}
> > +
> > +static int kunit_printk_emit(int level, const char *fmt, ...)
> > +{
> > + va_list args;
> > + int ret;
> > +
> > + va_start(args, fmt);
> > + ret = kunit_vprintk_emit(level, fmt, args);
> > + va_end(args);
> > +
> > + return ret;
> > +}
> > +
> > +static void kunit_vprintk(const struct kunit *test,
> > + const char *level,
> > + struct va_format *vaf)
> > +{
> > + kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
> > +}
> > +
> > +static bool kunit_has_printed_tap_version;
> > +
> > +static void kunit_print_tap_version(void)
> > +{
> > + if (!kunit_has_printed_tap_version) {
> > + kunit_printk_emit(LOGLEVEL_INFO, "TAP version 14\n");
> > + kunit_has_printed_tap_version = true;
> > + }
> > +}
> > +
> > +static size_t kunit_test_cases_len(struct kunit_case *test_cases)
> > +{
> > + struct kunit_case *test_case;
> > + size_t len = 0;
> > +
> > + for (test_case = test_cases; test_case->run_case; test_case++)
> > + len++;
> > +
> > + return len;
> > +}
> > +
> > +static void kunit_print_subtest_start(struct kunit_module *module)
> > +{
> > + kunit_print_tap_version();
> > + kunit_printk_emit(LOGLEVEL_INFO, "\t# Subtest: %s\n", module->name);
> > + kunit_printk_emit(LOGLEVEL_INFO,
> > + "\t1..%zd\n",
> > + kunit_test_cases_len(module->test_cases));
> > +}
> > +
> > +static void kunit_print_ok_not_ok(bool should_indent,
> > + bool is_ok,
> > + size_t test_number,
> > + const char *description)
> > +{
> > + const char *indent, *ok_not_ok;
> > +
> > + if (should_indent)
> > + indent = "\t";
> > + else
> > + indent = "";
> > +
> > + if (is_ok)
> > + ok_not_ok = "ok";
> > + else
> > + ok_not_ok = "not ok";
> > +
> > + kunit_printk_emit(LOGLEVEL_INFO,
> > + "%s%s %zd - %s\n",
> > + indent, ok_not_ok, test_number, description);
> > +}
> > +
> > +static bool kunit_module_has_succeeded(struct kunit_module *module)
> > +{
> > + struct kunit_case *test_case;
>
> This can be const?
Yep, nice catch.
> > + bool success = true;
> > +
> > + for (test_case = module->test_cases; test_case->run_case; test_case++)
> > + if (!test_case->success)
> > + success = false;
>
> Bail out early here on first "fail" with return false?
Will fix on next revision.
> > +
> > + return success;
> > +}
> > +
> > +size_t kunit_module_counter = 1;
> > +
> > +static void kunit_print_subtest_end(struct kunit_module *module)
> > +{
> > + kunit_print_ok_not_ok(false,
> > + kunit_module_has_succeeded(module),
> > + kunit_module_counter++,
> > + module->name);
> > +}
> > +
> > +static void kunit_print_test_case_ok_not_ok(struct kunit_case *test_case,
> > + size_t test_number)
> > +{
> > + kunit_print_ok_not_ok(true,
> > + test_case->success,
> > + test_number,
> > + test_case->name);
> > +}
> > +
> > +void kunit_init_test(struct kunit *test, const char *name)
> > +{
> > + spin_lock_init(&test->lock);
> > + test->name = name;
> > +}
> > +
> > +/*
> > + * Initializes and runs test case. Does not clean up or do post validations.
> > + */
> > +static void kunit_run_case_internal(struct kunit *test,
> > + struct kunit_module *module,
> > + struct kunit_case *test_case)
> > +{
> > + int ret;
> > +
> > + if (module->init) {
> > + ret = module->init(test);
> > + if (ret) {
> > + kunit_err(test, "failed to initialize: %d\n", ret);
> > + kunit_set_success(test, false);
> > + return;
> > + }
> > + }
> > +
> > + test_case->run_case(test);
> > +}
> > +
> > +/*
> > + * Performs post validations and cleanup after a test case was run.
> > + * XXX: Should ONLY BE CALLED AFTER kunit_run_case_internal!
> > + */
> > +static void kunit_run_case_cleanup(struct kunit *test,
> > + struct kunit_module *module,
> > + struct kunit_case *test_case)
>
> But test_case isn't used?
Whoops, will fix.
> > +{
> > + if (module->exit)
>
> Aha, so we don't need empty functions in the sysctl test.
Nope, sorry about that. That will be fixed in the next revision.
> > + module->exit(test);
> > +}
> > +
> > +/*
> > + * Performs all logic to run a test case.
> > + */
> > +static void kunit_run_case(struct kunit_module *module,
> > + struct kunit_case *test_case)
> > +{
> > + struct kunit test;
> > +
> > + kunit_init_test(&test, test_case->name);
> > + kunit_set_success(&test, true);
>
> Can kunit_init_test() also kunit_set_success() to true or false,
> depending on what is desired as the initial state?
>
> > +
> > + kunit_run_case_internal(&test, module, test_case);
> > + kunit_run_case_cleanup(&test, module, test_case);
>
> I find this odd, we have run_case_internal() that does two things, init
> and run_case, while case_cleanup() does one thing, call module->exit().
>
> Can we just inline all those functions in here so that it looks like
> this:
>
> int ret = 0;
>
> if (module->init) {
> ret = module->init(test);
> if (ret) {
> kunit_err(test, "failed to initialize: %d\n", ret);
> kunit_set_success(&test, false);
> }
> }
>
> if (!ret)
> test_case->run_case(&test);
>
> if (module->exit)
> module->exit(&test);
>
> return kunit_get_success(&test);
>
> Then I don't have to read two more functions to figure out the flow of
> running a test case.
Sorry about that. A lot more logic gets added to running test cases
later on in this patchset. This logic added "later" is actually older
than what's here, so I basically "unrefactored" something I had
already written to get this earlier patch.
In anycase, you are right; these little tiny functions don't make any
sense (yet); I will remove them in the next revision (and let the
later patch make these changes in a more organic looking way).
>
> > +
> > + test_case->success = kunit_get_success(&test);
> > +}
> > +
> > +int kunit_run_tests(struct kunit_module *module)
> > +{
> > + struct kunit_case *test_case;
> > + size_t test_case_count = 1;
>
> Might make sense to assign this to 0 first and then pre-increment so
> that test_case_count can't be 1 when there aren't any tests?
No, sorry, this is actually specified by the Test Anything Protocol
(TAP); it indexes it's tests starting at 1; not what I would have
done, but we (Greg, Frank, myself, and others) previously agreed that
KUnit should follow TAP[1].
Maybe the name of this variable is a bit misleading since it is the
"test number" or test index. Would `test_case_number` be better?
> > +
> > + kunit_print_subtest_start(module);
> > +
> > + for (test_case = module->test_cases; test_case->run_case; test_case++) {
> > + kunit_run_case(module, test_case);
> > + kunit_print_test_case_ok_not_ok(test_case, test_case_count++);
>
> Can this be pushed into kunit_run_case() and have that function take a
> test_case_count number? Maybe that would allow us to avoid storing
> test_case->success entirely? Assuming that kunit_run_case() returned a
> value like success or failure, then yes it would work.
Eh, I would prefer not to do that. I like keeping the
printing/reporting functions as orthogonal as possible; it kind of
mirrors the parsing logic on the test harness script side, and will
also be easier to pull out when I go back to improve the expectation
failure reporting when I get around to that later. Even if I never get
around to that, I think this will be much easier for me to maintain.
> unsigned int failed = 0;
>
> for (test_case = module->test_cases; test_case->run_case; test_case++) {
> failed |= kunit_run_case(module, test_case, ++test_case_count);
>
> kunit_print_ok_not_ok(false,
> !failed,
> kunit_module_counter++,
> module->name);
>
> > + kunit_print_subtest_end(module);
> > +
> > + return 0;
> > +}
[1] https://github.com/TestAnything/Specification/blob/tap-14-specification/specification.md#the-test-line
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-14 22:06 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <359e6f64d646d5305c52f393db5296c469630d11.camel@intel.com>
On 6/14/19 2:34 PM, Yu-cheng Yu wrote:
> On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
>>> I have a related question:
>>>
>>> Do we allow the application to read the bitmap, or any fault from the
>>> application on bitmap pages?
>>
>> We have to allow apps to read it. Otherwise they can't execute
>> instructions.
>
> What I meant was, if an app executes some legacy code that results in bitmap
> lookup, but the bitmap page is not yet populated, and if we then populate that
> page with all-zero, a #CP should follow. So do we even populate that zero page
> at all?
>
> I think we should; a #CP is more obvious to the user at least.
Please make an effort to un-Intel-ificate your messages as much as
possible. I'd really prefer that folks say "missing end branch fault"
rather than #CP. I had to Google "#CP".
I *think* you are saying that: The *only* lookups to this bitmap are on
"missing end branch" conditions. Normal, proper-functioning code
execution that has ENDBR instructions in it will never even look at the
bitmap. The only case when we reference the bitmap locations is when
the processor is about do do a "missing end branch fault" so that it can
be suppressed. Any population with the zero page would be done when
code had already encountered a "missing end branch" condition, and
populating with a zero-filled page will guarantee that a "missing end
branch fault" will result. You're arguing that we should just figure
this out at fault time and not ever reach the "missing end branch fault"
at all.
Is that right?
If so, that's an architecture subtlety that I missed until now and which
went entirely unmentioned in the changelog and discussion up to this
point. Let's make sure that nobody else has to walk that path by
improving our changelog, please.
In any case, I don't think this is worth special-casing our zero-fill
code, FWIW. It's not performance critical and not worth the complexity.
If apps want to handle the signals and abuse this to fill space up with
boring page table contents, they're welcome to. There are much easier
ways to consume a lot of memory.
>> We don't have to allow them to (popuating) fault on it. But, if we
>> don't, we need some kind of kernel interface to avoid the faults.
>
> The plan is:
>
> * Move STACK_TOP (and vdso) down to give space to the bitmap.
Even for apps with 57-bit address spaces?
> * Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code
> size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8).
The bitmap size is determined by CR4.LA57, not the app. If you place
the bitmap here, won't references to it for high addresses go into the
high address space?
Specifically, on a CR4.LA57=0 system, we have 48 bits of address space,
so 128TB for apps. You are proposing sticking the bitmap above the
stack which is near the top of that 128TB address space. But on a
5-level paging system with CR4.LA57=1, there could be valid data at
129GB. Is there something keeping that data from being mistaken for
being part of the bitmap?
Also, if you're limiting it to TASK_SIZE_LOW, please don't forget that
this is yet another thing that probably won't work with the vsyscall
page. Please make sure you consider it and mention it in your next post.
> * Mmap the space only when the app issues the first mark-legacy prctl. This
> avoids the core-dump issue for most apps and the accounting problem that
> MAP_NORESERVE probably won't solve completely.
What is this accounting problem?
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-14 21:34 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <598edca7-c36a-a236-3b72-08b2194eb609@intel.com>
On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
> On 6/14/19 10:13 AM, Yu-cheng Yu wrote:
> > On Fri, 2019-06-14 at 09:13 -0700, Dave Hansen wrote:
> > > On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
> > > > The bitmap is very big.
> > >
> > > Really? It's actually, what, 8*4096=32k, so 1/32,768th of the size of
> > > the libraries legacy libraries you load? Do our crash dumps really not
> > > know how to represent or deal with sparse mappings?
> >
> > Ok, even the core dump is not physically big, its size still looks odd,
> > right?
>
> Hell if I know.
>
> Could you please go try this in practice so that we're designing this
> thing fixing real actual problems instead of phantoms that we're
> anticipating?
>
> > Could this also affect how much time for GDB to load it.
>
> I don't know. Can you go find out for sure, please?
OK!
>
> > I have a related question:
> >
> > Do we allow the application to read the bitmap, or any fault from the
> > application on bitmap pages?
>
> We have to allow apps to read it. Otherwise they can't execute
> instructions.
What I meant was, if an app executes some legacy code that results in bitmap
lookup, but the bitmap page is not yet populated, and if we then populate that
page with all-zero, a #CP should follow. So do we even populate that zero page
at all?
I think we should; a #CP is more obvious to the user at least.
>
> We don't have to allow them to (popuating) fault on it. But, if we
> don't, we need some kind of kernel interface to avoid the faults.
The plan is:
* Move STACK_TOP (and vdso) down to give space to the bitmap.
* Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code
size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8).
* Mmap the space only when the app issues the first mark-legacy prctl. This
avoids the core-dump issue for most apps and the accounting problem that
MAP_NORESERVE probably won't solve completely.
* The bitmap is read-only. The kernel sets the bitmap with
get_user_pages_fast(FOLL_WRITE) and user_access_begin()/user_addess_end().
I will send out a RFC patch.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v4 19/28] docs: powerpc: convert docs to ReST and rename to *.rst
From: Bjorn Helgaas @ 2019-06-14 21:30 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Linas Vepstas,
Russell Currey, Sam Bobroff, Oliver O'Halloran,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Frederic Barrat, Andrew Donnellan, Manoj N. Kumar,
Matthew R. Ochs, Uma Krishnan, Qiang Zhao, Li Yang,
Greg Kroah-Hartman, Jiri Slaby, linux-pci, linuxppc-dev,
linux-scsi, linux-arm-kernel, Andrew Donnellan
In-Reply-To: <20190614143635.3aff154d@lwn.net>
On Fri, Jun 14, 2019 at 02:36:35PM -0600, Jonathan Corbet wrote:
> On Wed, 12 Jun 2019 14:52:55 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Convert docs to ReST and add them to the arch-specific
> > book.
> >
> > The conversion here was trivial, as almost every file there
> > was already using an elegant format close to ReST standard.
> >
> > The changes were mostly to mark literal blocks and add a few
> > missing section title identifiers.
> >
> > One note with regards to "--": on Sphinx, this can't be used
> > to identify a list, as it will format it badly. This can be
> > used, however, to identify a long hyphen - and "---" is an
> > even longer one.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
>
> This one fails to apply because ...
>
> [...]
>
> > diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
> > index 83db42092935..acc21ecca322 100644
> > --- a/Documentation/PCI/pci-error-recovery.rst
> > +++ b/Documentation/PCI/pci-error-recovery.rst
> > @@ -403,7 +403,7 @@ That is, the recovery API only requires that:
> > .. note::
> >
> > Implementation details for the powerpc platform are discussed in
> > - the file Documentation/powerpc/eeh-pci-error-recovery.txt
> > + the file Documentation/powerpc/eeh-pci-error-recovery.rst
> >
> > As of this writing, there is a growing list of device drivers with
> > patches implementing error recovery. Not all of these patches are in
> > @@ -422,3 +422,24 @@ That is, the recovery API only requires that:
> > - drivers/net/cxgb3
> > - drivers/net/s2io.c
> > - drivers/net/qlge
> > +
> > +>>> As of this writing, there is a growing list of device drivers with
> > +>>> patches implementing error recovery. Not all of these patches are in
> > +>>> mainline yet. These may be used as "examples":
> > +>>>
> > +>>> drivers/scsi/ipr
> > +>>> drivers/scsi/sym53c8xx_2
> > +>>> drivers/scsi/qla2xxx
> > +>>> drivers/scsi/lpfc
> > +>>> drivers/next/bnx2.c
> > +>>> drivers/next/e100.c
> > +>>> drivers/net/e1000
> > +>>> drivers/net/e1000e
> > +>>> drivers/net/ixgb
> > +>>> drivers/net/ixgbe
> > +>>> drivers/net/cxgb3
> > +>>> drivers/net/s2io.c
> > +>>> drivers/net/qlge
>
> ...of this, which has the look of a set of conflict markers that managed
> to get committed...?
I don't see these conflict markers in my local branch or in
linux-next (next-20190614).
Let me know if I need to do something.
Bjorn
^ permalink raw reply
* Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst
From: Bjorn Helgaas @ 2019-06-14 21:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Sebastian Reichel,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown,
Mathieu Poirier, Suzuki K Poulose, Harry Wei, Alex Shi,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Johannes Berg, David S. Miller, linux-pm,
linux-arm-kernel, intel-gfx, dri-devel, linux-pci, linux-wireless,
netdev, Srivatsa S . Bhat
In-Reply-To: <20190614143631.7c99719f@lwn.net>
On Fri, Jun 14, 2019 at 02:36:31PM -0600, Jonathan Corbet wrote:
> On Thu, 13 Jun 2019 07:10:36 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identify paragraphs;
> > - fix tables markups;
> > - add some lists markups;
> > - mark literal blocks;
> > - adjust title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
>
> So I can't apply this one due to conflicts in include/linux/pci.h. Bjorn,
> perhaps the easiest thing is for you to take this one through your tree?
OK, I applied this to pci/docs for v5.3. I applied this entire patch,
but if you would prefer that I only apply the PCI-related parts, let
me know and I'll split those out.
Bjorn
^ permalink raw reply
* INQUIRY -AGRA POLANDS
From: Mrkt dept @ 2019-06-14 20:33 UTC (permalink / raw)
To: Recipients
Hello Sir,
Greetings rom Agra Polands.
we have been building our international business since 1997, dealing with a wide range of luxury consumer goods in order to efficiently and effectively satisfy all our customers’ demands.
Kindly confirm if you be able to supply us with our desired items.
What is your Payment terms and Shipments?.
Regards
Riccardo Corbo
International Buyer & Analyst
Address:Via Trento, 7/F - Lomazzo (CO) - Italy VAT IT 12165160156
agra.poland@aol.com
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-14 20:57 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <b5a915602020a6ce26ea1254f7f60e239c91bc9f.camel@intel.com>
On 6/14/19 10:13 AM, Yu-cheng Yu wrote:
> On Fri, 2019-06-14 at 09:13 -0700, Dave Hansen wrote:
>> On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
>>> The bitmap is very big.
>>
>> Really? It's actually, what, 8*4096=32k, so 1/32,768th of the size of
>> the libraries legacy libraries you load? Do our crash dumps really not
>> know how to represent or deal with sparse mappings?
>
> Ok, even the core dump is not physically big, its size still looks odd, right?
Hell if I know.
Could you please go try this in practice so that we're designing this
thing fixing real actual problems instead of phantoms that we're
anticipating?
> Could this also affect how much time for GDB to load it.
I don't know. Can you go find out for sure, please?
> I have a related question:
>
> Do we allow the application to read the bitmap, or any fault from the
> application on bitmap pages?
We have to allow apps to read it. Otherwise they can't execute
instructions.
We don't have to allow them to (popuating) fault on it. But, if we
don't, we need some kind of kernel interface to avoid the faults.
^ permalink raw reply
* Re: [RESEND PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Jonathan Corbet @ 2019-06-14 20:44 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: linuxppc-dev, arnd, bhupesh.linux, mpe, benh, paulus,
linux-kernel, linux-doc
In-Reply-To: <1560161019-3895-1-git-send-email-bhsharma@redhat.com>
On Mon, 10 Jun 2019 15:33:39 +0530
Bhupesh Sharma <bhsharma@redhat.com> wrote:
> powerpc architecture (both 64-bit and 32-bit) supports stack protector
> mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> add stack protector support")].
>
> Update stackprotector arch support documentation to reflect the same.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> Resend, this time Cc'ing Jonathan and doc-list.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] sphinx.rst: Add note about code snippets embedded in the text
From: Jonathan Corbet @ 2019-06-14 20:39 UTC (permalink / raw)
To: André Almeida; +Cc: linux-doc, linux-kernel, kernel
In-Reply-To: <20190611200316.30054-1-andrealmeid@collabora.com>
On Tue, 11 Jun 2019 17:03:16 -0300
André Almeida <andrealmeid@collabora.com> wrote:
> There's a paragraph that explains how to create fixed width text block,
> but it doesn't explains how to create fixed width text inline, although
> this feature is really used through the documentation. Fix that adding a
> quick note about it.
>
> Signed-off-by: André Almeida <andrealmeid@collabora.com>
Applied, thanks. But I do agree with Jani that we don't want to reproduce
the RST guide here.
jon
^ permalink raw reply
* Re: [PATCH] scripts/documentation-file-ref-check: ignore output dir
From: Jonathan Corbet @ 2019-06-14 20:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <093d01459be472a20894c5be6f9b937ff7fd7d47.1560421751.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019 07:29:17 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> When there's no Documentation/output directory, the script will
> complain about those missing references:
>
> Documentation/doc-guide/sphinx.rst: Documentation/output
> Documentation/doc-guide/sphinx.rst: Documentation/output
> Documentation/process/howto.rst: Documentation/output
> Documentation/translations/it_IT/doc-guide/sphinx.rst: Documentation/output
> Documentation/translations/it_IT/doc-guide/sphinx.rst: Documentation/output
> Documentation/translations/it_IT/process/howto.rst: Documentation/output
> Documentation/translations/ja_JP/howto.rst: Documentation/output
> Documentation/translations/ko_KR/howto.rst: Documentation/output
>
> Those are false positives, so add an ignore rule for them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v4 14/28] docs: locking: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Peter Zijlstra, Ingo Molnar, Will Deacon, Federico Vaga,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, dri-devel
In-Reply-To: <791f74dab9607d3d349b1e7fe5d0ab5abbb24081.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:50 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert the locking documents to ReST and add them to the
> kernel development book where it belongs.
>
> Most of the stuff here is just to make Sphinx to properly
> parse the text file, as they're already in good shape,
> not requiring massive changes in order to be parsed.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
This patch contains linux-next changes and doesn't apply to docs-next.
Perhaps the best thing to do is to apply it to the locking tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Sebastian Reichel, Rafael J. Wysocki, Viresh Kumar, Len Brown,
Pavel Machek, Nishanth Menon, Stephen Boyd, Liam Girdwood,
Mark Brown, Mathieu Poirier, Suzuki K Poulose, Harry Wei,
Alex Shi, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Bjorn Helgaas, Johannes Berg,
David S. Miller, linux-pm, linux-arm-kernel, intel-gfx, dri-devel,
linux-pci, linux-wireless, netdev, Srivatsa S . Bhat
In-Reply-To: <72d1f8f360d395958dd0b49165fc51b58801f57e.1560420621.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019 07:10:36 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
So I can't apply this one due to conflicts in include/linux/pci.h. Bjorn,
perhaps the easiest thing is for you to take this one through your tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 00/28] Convert files to ReST - part 1
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Greentime Hu,
Vincent Chen, linux-riscv, netdev, bpf
In-Reply-To: <cover.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:36 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> This is mostly a rebase of the /33 series v3 I sent, on the top of the latest
> linux-next (next-20190612).
>
> Changes from v3:
>
> - dropped cpufreq conversion - documents are too outdated;
> - infiniband patch is not here anymore - as it should be merged via RDMA;
> - s390 patches were already merged;
> - Dropped Geert as Maintainer from fb/framebuffer.rst, as per his request;
> - Did a minor editorial change at popwerpc/cxl.rst per Andrew Donellan
> request;
> - Added acks/reviews;
> - trivial rebase fixups.
So I had to pull docs-next forward to -rc4, but then I was able to apply
this set except for parts 5, 6, 14, 18, and 19. Some progress made, but
this is somewhat painful work...
jon
^ permalink raw reply
* Re: [PATCH v4 19/28] docs: powerpc: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Linas Vepstas, Russell Currey, Sam Bobroff, Oliver O'Halloran,
Bjorn Helgaas, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Frederic Barrat, Andrew Donnellan,
Manoj N. Kumar, Matthew R. Ochs, Uma Krishnan, Qiang Zhao,
Li Yang, Greg Kroah-Hartman, Jiri Slaby, linux-pci, linuxppc-dev,
linux-scsi, linux-arm-kernel, Andrew Donnellan
In-Reply-To: <63560c1ee7174952e148a353840a17969fe0be2d.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:55 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert docs to ReST and add them to the arch-specific
> book.
>
> The conversion here was trivial, as almost every file there
> was already using an elegant format close to ReST standard.
>
> The changes were mostly to mark literal blocks and add a few
> missing section title identifiers.
>
> One note with regards to "--": on Sphinx, this can't be used
> to identify a list, as it will format it badly. This can be
> used, however, to identify a long hyphen - and "---" is an
> even longer one.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
This one fails to apply because ...
[...]
> diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
> index 83db42092935..acc21ecca322 100644
> --- a/Documentation/PCI/pci-error-recovery.rst
> +++ b/Documentation/PCI/pci-error-recovery.rst
> @@ -403,7 +403,7 @@ That is, the recovery API only requires that:
> .. note::
>
> Implementation details for the powerpc platform are discussed in
> - the file Documentation/powerpc/eeh-pci-error-recovery.txt
> + the file Documentation/powerpc/eeh-pci-error-recovery.rst
>
> As of this writing, there is a growing list of device drivers with
> patches implementing error recovery. Not all of these patches are in
> @@ -422,3 +422,24 @@ That is, the recovery API only requires that:
> - drivers/net/cxgb3
> - drivers/net/s2io.c
> - drivers/net/qlge
> +
> +>>> As of this writing, there is a growing list of device drivers with
> +>>> patches implementing error recovery. Not all of these patches are in
> +>>> mainline yet. These may be used as "examples":
> +>>>
> +>>> drivers/scsi/ipr
> +>>> drivers/scsi/sym53c8xx_2
> +>>> drivers/scsi/qla2xxx
> +>>> drivers/scsi/lpfc
> +>>> drivers/next/bnx2.c
> +>>> drivers/next/e100.c
> +>>> drivers/net/e1000
> +>>> drivers/net/e1000e
> +>>> drivers/net/ixgb
> +>>> drivers/net/ixgbe
> +>>> drivers/net/cxgb3
> +>>> drivers/net/s2io.c
> +>>> drivers/net/qlge
...of this, which has the look of a set of conflict markers that managed
to get committed...?
jon
^ permalink raw reply
* Re: [PATCH v4 02/28] docs: arm64: convert docs to ReST and rename to .rst
From: Jonathan Corbet @ 2019-06-14 20:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Catalin Marinas, Will Deacon, Harry Wei, Alex Shi, Paolo Bonzini,
Radim Krčmář, Ard Biesheuvel, linux-arm-kernel,
kvm, linux-efi
In-Reply-To: <20190614141041.335a76e5@lwn.net>
On Fri, 14 Jun 2019 14:10:41 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> On Wed, 12 Jun 2019 14:52:38 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > The documentation is in a format that is very close to ReST format.
> >
> > The conversion is actually:
> > - add blank lines in order to identify paragraphs;
> > - fixing tables markups;
> > - adding some lists markups;
> > - marking literal blocks;
> > - adjust some title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
>
> This one doesn't apply to docs-next, since there's a bunch of stuff in
> linux-next that I don't have. I'd suggest that it either go by way of an
> ARM tree or send it my way again after the ARM changes go upstream.
Actually, nevermind. Pulling my tree forward to 5.2-rc4 resolved the
issues here.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 05/28] docs: cgroup-v1: convert docs to ReST and rename to *.rst
From: Tejun Heo @ 2019-06-14 20:30 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, x86, Jens Axboe, Li Zefan,
Johannes Weiner, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, James Morris,
Serge E. Hallyn, linux-block, cgroups, netdev, bpf,
linux-security-module
In-Reply-To: <20190614141401.48bfb266@lwn.net>
On Fri, Jun 14, 2019 at 02:14:01PM -0600, Jonathan Corbet wrote:
> On Wed, 12 Jun 2019 14:52:41 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Convert the cgroup-v1 files to ReST format, in order to
> > allow a later addition to the admin-guide.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identify paragraphs;
> > - fix tables markups;
> > - add some lists markups;
> > - mark literal blocks;
> > - adjust title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Tejun Heo <tj@kernel.org>
>
> This one, too, has linux-next stuff that keeps it from applying to
> docs-next. Tejun, would you like to carry it on top of your work?
Applied to cgroup/for-5.3.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v5 1/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-06-14 20:21 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, Sasha Levin
In-Reply-To: <20190614202127.26812-1-sashal@kernel.org>
This patch adds support for a software-only implementation of a TPM
running in TEE.
There is extensive documentation of the design here:
https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ .
As well as reference code for the firmware available here:
https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM
Tested-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
Signed-off-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 382 ++++++++++++++++++++++++++++++++
drivers/char/tpm/tpm_ftpm_tee.h | 40 ++++
4 files changed, 428 insertions(+)
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 88a3c06fc153..facee3bb5607 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -164,6 +164,11 @@ config TCG_VTPM_PROXY
/dev/vtpmX and a server-side file descriptor on which the vTPM
can receive commands.
+config TCG_FTPM_TEE
+ tristate "TEE based fTPM Interface"
+ depends on TEE && OPTEE
+ ---help---
+ This driver proxies for fTPM running in TEE
source "drivers/char/tpm/st33zp24/Kconfig"
endif # TCG_TPM
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a01c4cab902a..c354cdff9c62 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
obj-$(CONFIG_TCG_CRB) += tpm_crb.o
obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
+obj-$(CONFIG_TCG_FTPM_TEE) += tpm_ftpm_tee.o
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
new file mode 100644
index 000000000000..2bfa5b1d4c06
--- /dev/null
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Microsoft Corporation
+ *
+ * Implements a firmware TPM as described here:
+ * https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/
+ *
+ * A reference implementation is available here:
+ * https://github.com/microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM
+ */
+
+#include <linux/acpi.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/tee_drv.h>
+#include <linux/tpm.h>
+#include <linux/uuid.h>
+
+#include "tpm.h"
+#include "tpm_ftpm_tee.h"
+
+#define DRIVER_NAME "ftpm-tee"
+
+/*
+ * TA_FTPM_UUID: BC50D971-D4C9-42C4-82CB-343FB7F37896
+ *
+ * Randomly generated, and must correspond to the GUID on the TA side.
+ * Defined here in the reference implementation:
+ * https://github.com/microsoft/ms-tpm-20-ref/blob/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM/include/fTPM.h#L42
+ */
+
+static const uuid_t ftpm_ta_uuid =
+ UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+ 0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x96);
+
+/**
+ * ftpm_tee_tpm_op_recv - retrieve fTPM response.
+ *
+ * @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h.
+ * @buf: the buffer to store data.
+ * @count: the number of bytes to read.
+ *
+ * Return:
+ * In case of success the number of bytes received.
+ * On failure, -errno.
+ */
+static int ftpm_tee_tpm_op_recv(struct tpm_chip *chip, u8 *buf, size_t count)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
+ size_t len;
+
+ len = pvt_data->resp_len;
+ if (count < len) {
+ dev_err(&chip->dev,
+ "%s:Invalid size in recv: count=%zd, resp_len=%zd\n",
+ __func__, count, len);
+ return -EIO;
+ }
+
+ memcpy(buf, pvt_data->resp_buf, len);
+ pvt_data->resp_len = 0;
+
+ return len;
+}
+
+/**
+ * ftpm_tee_tpm_op_send - send TPM commands through the TEE shared memory.
+ *
+ * @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h
+ * @buf: the buffer to send.
+ * @len: the number of bytes to send.
+ *
+ * Return:
+ * In case of success, returns 0.
+ * On failure, -errno
+ */
+static int ftpm_tee_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t len)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
+ size_t resp_len;
+ int rc;
+ u8 *temp_buf;
+ struct tpm_header *resp_header;
+ struct tee_ioctl_invoke_arg transceive_args;
+ struct tee_param command_params[4];
+ struct tee_shm *shm = pvt_data->shm;
+
+ if (len > MAX_COMMAND_SIZE) {
+ dev_err(&chip->dev,
+ "%s:len=%zd exceeds MAX_COMMAND_SIZE supported by fTPM TA\n",
+ __func__, len);
+ return -EIO;
+ }
+
+ memset(&transceive_args, 0, sizeof(transceive_args));
+ memset(command_params, 0, sizeof(command_params));
+ pvt_data->resp_len = 0;
+
+ /* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of fTPM TA */
+ transceive_args = (struct tee_ioctl_invoke_arg) {
+ .func = FTPM_OPTEE_TA_SUBMIT_COMMAND,
+ .session = pvt_data->session,
+ .num_params = 4,
+ };
+
+ /* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
+ command_params[0] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
+ .u.memref = {
+ .shm = shm,
+ .size = len,
+ .shm_offs = 0,
+ },
+ };
+
+ temp_buf = tee_shm_get_va(shm, 0);
+ if (IS_ERR(temp_buf)) {
+ dev_err(&chip->dev, "%s:tee_shm_get_va failed for transmit\n",
+ __func__);
+ return PTR_ERR(temp_buf);
+ }
+ memset(temp_buf, 0, (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE));
+
+ memcpy(temp_buf, buf, len);
+
+ command_params[1] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
+ .u.memref = {
+ .shm = shm,
+ .size = MAX_RESPONSE_SIZE,
+ .shm_offs = MAX_COMMAND_SIZE,
+ },
+ };
+
+ rc = tee_client_invoke_func(pvt_data->ctx, &transceive_args,
+ command_params);
+ if ((rc < 0) || (transceive_args.ret != 0)) {
+ dev_err(&chip->dev, "%s:SUBMIT_COMMAND invoke error: 0x%x\n",
+ __func__, transceive_args.ret);
+ return (rc < 0) ? rc : transceive_args.ret;
+ }
+
+ temp_buf = tee_shm_get_va(shm, command_params[1].u.memref.shm_offs);
+ if (IS_ERR(temp_buf)) {
+ dev_err(&chip->dev, "%s:tee_shm_get_va failed for receive\n",
+ __func__);
+ return PTR_ERR(temp_buf);
+ }
+
+ resp_header = (struct tpm_header *)temp_buf;
+ resp_len = be32_to_cpu(resp_header->length);
+
+ /* sanity check resp_len */
+ if (resp_len < TPM_HEADER_SIZE) {
+ dev_err(&chip->dev, "%s:tpm response header too small\n",
+ __func__);
+ return -EIO;
+ }
+ if (resp_len > MAX_RESPONSE_SIZE) {
+ dev_err(&chip->dev,
+ "%s:resp_len=%zd exceeds MAX_RESPONSE_SIZE\n",
+ __func__, resp_len);
+ return -EIO;
+ }
+
+ /* sanity checks look good, cache the response */
+ memcpy(pvt_data->resp_buf, temp_buf, resp_len);
+ pvt_data->resp_len = resp_len;
+
+ return 0;
+}
+
+static void ftpm_tee_tpm_op_cancel(struct tpm_chip *chip)
+{
+ /* not supported */
+}
+
+static u8 ftpm_tee_tpm_op_status(struct tpm_chip *chip)
+{
+ return 0;
+}
+
+static bool ftpm_tee_tpm_req_canceled(struct tpm_chip *chip, u8 status)
+{
+ return 0;
+}
+
+static const struct tpm_class_ops ftpm_tee_tpm_ops = {
+ .flags = TPM_OPS_AUTO_STARTUP,
+ .recv = ftpm_tee_tpm_op_recv,
+ .send = ftpm_tee_tpm_op_send,
+ .cancel = ftpm_tee_tpm_op_cancel,
+ .status = ftpm_tee_tpm_op_status,
+ .req_complete_mask = 0,
+ .req_complete_val = 0,
+ .req_canceled = ftpm_tee_tpm_req_canceled,
+};
+
+/*
+ * Check whether this driver supports the fTPM TA in the TEE instance
+ * represented by the params (ver/data) to this function.
+ */
+static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+ /*
+ * Currently this driver only support GP Complaint OPTEE based fTPM TA
+ */
+ if ((ver->impl_id == TEE_IMPL_ID_OPTEE) &&
+ (ver->gen_caps & TEE_GEN_CAP_GP))
+ return 1;
+ else
+ return 0;
+}
+
+/*
+ * Undo what has been done in ftpm_tee_probe
+ */
+static void ftpm_tee_deinit(struct ftpm_tee_private *pvt_data)
+{
+ /* Release the chip */
+ tpm_chip_unregister(pvt_data->chip);
+
+ /* frees chip */
+ if (pvt_data->chip)
+ put_device(&pvt_data->chip->dev);
+
+ if (pvt_data->ctx) {
+ /* Free the shared memory pool */
+ tee_shm_free(pvt_data->shm);
+
+ /* close the existing session with fTPM TA*/
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+
+ /* close the context with TEE driver */
+ tee_client_close_context(pvt_data->ctx);
+ }
+
+ /* memory allocated with devm_kzalloc() is freed automatically */
+}
+
+/**
+ * ftpm_tee_probe - initialize the fTPM
+ * @pdev: the platform_device description.
+ *
+ * Return:
+ * On success, 0. On failure, -errno.
+ */
+static int ftpm_tee_probe(struct platform_device *pdev)
+{
+ int rc;
+ struct tpm_chip *chip;
+ struct device *dev = &pdev->dev;
+ struct ftpm_tee_private *pvt_data = NULL;
+ struct tee_ioctl_open_session_arg sess_arg;
+
+ pvt_data = devm_kzalloc(dev, sizeof(struct ftpm_tee_private),
+ GFP_KERNEL);
+ if (!pvt_data)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, pvt_data);
+
+ /* Open context with TEE driver */
+ pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
+ NULL);
+ if (IS_ERR(pvt_data->ctx)) {
+ if (ERR_PTR(pvt_data->ctx) == -ENOENT)
+ return -EPROBE_DEFER;
+ dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
+ return ERR_PTR(pvt_data->ctx);
+ }
+
+ /* Open a session with fTPM TA */
+ memset(&sess_arg, 0, sizeof(sess_arg));
+ memcpy(sess_arg.uuid, ftpm_ta_uuid.b, TEE_IOCTL_UUID_LEN);
+ sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+ sess_arg.num_params = 0;
+
+ rc = tee_client_open_session(pvt_data->ctx, &sess_arg, NULL);
+ if ((rc < 0) || (sess_arg.ret != 0)) {
+ dev_err(dev, "%s:tee_client_open_session failed, err=%x\n",
+ __func__, sess_arg.ret);
+ rc = -EINVAL;
+ goto out_tee_session;
+ }
+ pvt_data->session = sess_arg.session;
+
+ /* Allocate dynamic shared memory with fTPM TA */
+ pvt_data->shm = tee_shm_alloc(pvt_data->ctx,
+ (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE),
+ TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
+ if (IS_ERR(pvt_data->shm)) {
+ dev_err(dev, "%s:tee_shm_alloc failed\n", __func__);
+ rc = -ENOMEM;
+ goto out_shm_alloc;
+ }
+
+ /* Allocate new struct tpm_chip instance */
+ chip = tpm_chip_alloc(dev, &ftpm_tee_tpm_ops);
+ if (IS_ERR(chip)) {
+ dev_err(dev, "%s:tpm_chip_alloc failed\n", __func__);
+ rc = PTR_ERR(chip);
+ goto out_chip_alloc;
+ }
+
+ pvt_data->chip = chip;
+ pvt_data->chip->flags |= TPM_CHIP_FLAG_TPM2;
+
+ /* Create a character device for the fTPM */
+ rc = tpm_chip_register(pvt_data->chip);
+ if (rc) {
+ dev_err(dev, "%s:tpm_chip_register failed with rc=%d\n",
+ __func__, rc);
+ goto out_chip;
+ }
+
+ return 0;
+
+out_chip:
+ put_device(&pvt_data->chip->dev);
+out_chip_alloc:
+ tee_shm_free(pvt_data->shm);
+out_shm_alloc:
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+out_tee_session:
+ tee_client_close_context(pvt_data->ctx);
+
+ return rc;
+}
+
+/**
+ * ftpm_tee_remove - remove the TPM device
+ * @pdev: the platform_device description.
+ *
+ * Return:
+ * 0 in case of success.
+ */
+static int ftpm_tee_remove(struct platform_device *pdev)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(&pdev->dev);
+
+ /* Release the chip */
+ tpm_chip_unregister(pvt_data->chip);
+
+ /* frees chip */
+ put_device(&pvt_data->chip->dev);
+
+ /* Free the shared memory pool */
+ tee_shm_free(pvt_data->shm);
+
+ /* close the existing session with fTPM TA*/
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+
+ /* close the context with TEE driver */
+ tee_client_close_context(pvt_data->ctx);
+
+ /* memory allocated with devm_kzalloc() is freed automatically */
+
+ return 0;
+}
+
+static const struct of_device_id of_ftpm_tee_ids[] = {
+ { .compatible = "microsoft,ftpm" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids);
+
+static struct platform_driver ftpm_tee_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(of_ftpm_tee_ids),
+ },
+ .probe = ftpm_tee_probe,
+ .remove = ftpm_tee_remove,
+};
+
+module_platform_driver(ftpm_tee_driver);
+
+MODULE_AUTHOR("Thirupathaiah Annapureddy <thiruan@microsoft.com>");
+MODULE_DESCRIPTION("TPM Driver for fTPM TA in TEE");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/char/tpm/tpm_ftpm_tee.h b/drivers/char/tpm/tpm_ftpm_tee.h
new file mode 100644
index 000000000000..b09ee7be4545
--- /dev/null
+++ b/drivers/char/tpm/tpm_ftpm_tee.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) Microsoft Corporation
+ */
+
+#ifndef __TPM_FTPM_TEE_H__
+#define __TPM_FTPM_TEE_H__
+
+#include <linux/tee_drv.h>
+#include <linux/tpm.h>
+#include <linux/uuid.h>
+
+/* The TAFs ID implemented in this TA */
+#define FTPM_OPTEE_TA_SUBMIT_COMMAND (0)
+#define FTPM_OPTEE_TA_EMULATE_PPI (1)
+
+/* max. buffer size supported by fTPM */
+#define MAX_COMMAND_SIZE 4096
+#define MAX_RESPONSE_SIZE 4096
+
+/**
+ * struct ftpm_tee_private - fTPM's private data
+ * @chip: struct tpm_chip instance registered with tpm framework.
+ * @state: internal state
+ * @session: fTPM TA session identifier.
+ * @resp_len: cached response buffer length.
+ * @resp_buf: cached response buffer.
+ * @ctx: TEE context handler.
+ * @shm: Memory pool shared with fTPM TA in TEE.
+ */
+struct ftpm_tee_private {
+ struct tpm_chip *chip;
+ u32 session;
+ size_t resp_len;
+ u8 resp_buf[MAX_RESPONSE_SIZE];
+ struct tee_context *ctx;
+ struct tee_shm *shm;
+};
+
+#endif /* __TPM_FTPM_TEE_H__ */
--
2.20.1
^ permalink raw reply related
* [PATCH v5 2/2] fTPM: add documentation for ftpm driver
From: Sasha Levin @ 2019-06-14 20:21 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, Sasha Levin
In-Reply-To: <20190614202127.26812-1-sashal@kernel.org>
This patch adds basic documentation to describe the new fTPM driver.
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/security/tpm/index.rst | 1 +
Documentation/security/tpm/tpm_ftpm_tee.rst | 31 +++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst
index af77a7bbb070..15783668644f 100644
--- a/Documentation/security/tpm/index.rst
+++ b/Documentation/security/tpm/index.rst
@@ -4,4 +4,5 @@ Trusted Platform Module documentation
.. toctree::
+ tpm_ftpm_tee
tpm_vtpm_proxy
diff --git a/Documentation/security/tpm/tpm_ftpm_tee.rst b/Documentation/security/tpm/tpm_ftpm_tee.rst
new file mode 100644
index 000000000000..29c2f8b5ed10
--- /dev/null
+++ b/Documentation/security/tpm/tpm_ftpm_tee.rst
@@ -0,0 +1,31 @@
+=============================================
+Firmware TPM Driver
+=============================================
+
+| Authors:
+| Thirupathaiah Annapureddy <thiruan@microsoft.com>
+| Sasha Levin <sashal@kernel.org>
+
+This document describes the firmware Trusted Platform Module (fTPM)
+device driver.
+
+Introduction
+============
+
+This driver is a shim for a firmware implemented in ARM's TrustZone
+environment. The driver allows programs to interact with the TPM in the same
+way the would interact with a hardware TPM.
+
+Design
+======
+
+The driver acts as a thin layer that passes commands to and from a TPM
+implemented in firmware. The driver itself doesn't contain much logic and is
+used more like a dumb pipe between firmware and kernel/userspace.
+
+The firmware itself is based on the following paper:
+https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf
+
+When the driver is loaded it will expose ``/dev/tpmX`` character devices to
+userspace which will enable userspace to communicate with the firmware tpm
+through this device.
--
2.20.1
^ permalink raw reply related
* [PATCH v5 0/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-06-14 20:21 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, Sasha Levin
Changes from v4:
- Don't show an error message while waiting for OP-TEE to come up.
Sasha Levin (2):
fTPM: firmware TPM running in TEE
fTPM: add documentation for ftpm driver
Documentation/security/tpm/index.rst | 1 +
Documentation/security/tpm/tpm_ftpm_tee.rst | 31 ++
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 382 ++++++++++++++++++++
drivers/char/tpm/tpm_ftpm_tee.h | 40 ++
6 files changed, 460 insertions(+)
create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
--
2.20.1
^ permalink raw reply
* Re: [PATCH v4 05/28] docs: cgroup-v1: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:14 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, Jens Axboe, Tejun Heo, Li Zefan, Johannes Weiner,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, James Morris, Serge E. Hallyn, linux-block,
cgroups, netdev, bpf, linux-security-module
In-Reply-To: <c1dd623359f44f05863456b8bceba0d8f3e42f38.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:41 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert the cgroup-v1 files to ReST format, in order to
> allow a later addition to the admin-guide.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Tejun Heo <tj@kernel.org>
This one, too, has linux-next stuff that keeps it from applying to
docs-next. Tejun, would you like to carry it on top of your work?
(This means I won't be able to apply #6 either, naturally).
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 02/28] docs: arm64: convert docs to ReST and rename to .rst
From: Jonathan Corbet @ 2019-06-14 20:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Catalin Marinas, Will Deacon, Harry Wei, Alex Shi, Paolo Bonzini,
Radim Krčmář, Ard Biesheuvel, linux-arm-kernel,
kvm, linux-efi
In-Reply-To: <8320e8e871660bf9fc426bc688f4808a1a7aa031.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:38 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> The documentation is in a format that is very close to ReST format.
>
> The conversion is actually:
> - add blank lines in order to identify paragraphs;
> - fixing tables markups;
> - adding some lists markups;
> - marking literal blocks;
> - adjust some title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
This one doesn't apply to docs-next, since there's a bunch of stuff in
linux-next that I don't have. I'd suggest that it either go by way of an
ARM tree or send it my way again after the ARM changes go upstream.
Thanks,
jon
^ permalink raw reply
* [PATCH v2 00/16] Add support to generate ABI documentation at admin-guide
From: Mauro Carvalho Chehab @ 2019-06-14 18:07 UTC (permalink / raw)
To: Linux Doc Mailing List, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, Rajat Jain,
Bjorn Helgaas
In-Reply-To: <3b8d7c64f887ddea01df3c4eeabc745c8ec45406.1560534648.git.mchehab+samsung@kernel.org>
Greg,
In time: forgot to add a 00/16 patch... someone come to my desk while I was
sending this... sorry for that.
That's the second version of the doc ABI updated logic.
Changes from version 1:
- I updated my e-mail on older patches;
- Two new ABI fix patches;
- Improved the parser to detect a few more issues I discovered on
some ABI files.
- There's now a "validate" command at get_abi.pl. It simply runs
the parser without any output, except for warnings;
- It now runs "get_abi.pl validate" during the build (if enabled).
Please notice that the last patch will conflict with another patch
merged via docs-next tree, with creates a Documentation/Kconfig and
adds a check at Documentation/Makefile for broken documentation
links. The conflict is trivial to solve, through: just add the contents
on both tress.
This series is based on your driver-core git tree.
-
On this series:
- The first two patches contain two extra ABI fixes;
- The next 10 patches contain the ABI parsing script. I don't
mind if you prefer folding them on a single patch, but IMO,
preserving the history may help tracking bugs, if any;
- The 13th patch adds the new script to the documentation build
system, together with a new python Sphinx extension with calls it;
- The 14th patch fixes the python script when running with newer
Sphinx versions (1.7 and upper);
- The 15th patch fixes an UTF-8 troubles;
- The final patch adds a Kconfig var that will check for ABI
file problems, if COMPILE_TEST and WARN_ABI_ERRORS are
enabled.
Mauro Carvalho Chehab (16):
ABI: sysfs-bus-pci-devices-aer_stats uses an invalid tag
ABI: Fix KernelVersion tags
scripts: add an script to parse the ABI files
scripts/get_abi.pl: parse files with text at beginning
scripts/get_abi.pl: avoid use literal blocks when not needed
scripts/get_abi.pl: split label naming from xref logic
scripts/get_abi.pl: add support for searching for ABI symbols
scripts/get_abi.pl: represent what in tables
scripts/get_abi.pl: fix parse issues with some files
scripts/get_abi.pl: avoid creating duplicate names
scripts/get_abi.pl: add a handler for invalid "where" tag
scripts/get_abi.pl: add a validate command
doc-rst: add ABI documentation to the admin-guide book
docs: sphinx/kernel_abi.py: fix UTF-8 support
sphinx/kernel_abi.py: make it compatible with Sphinx 1.7+
docs: Kconfig/Makefile: add a check for broken ABI files
Documentation/ABI/testing/pstore | 2 +-
.../sysfs-bus-event_source-devices-format | 2 +-
.../ABI/testing/sysfs-bus-i2c-devices-hm6352 | 6 +-
.../testing/sysfs-bus-pci-devices-aer_stats | 24 +-
.../ABI/testing/sysfs-bus-pci-devices-cciss | 22 +-
.../testing/sysfs-bus-usb-devices-usbsevseg | 10 +-
.../ABI/testing/sysfs-driver-altera-cvp | 2 +-
Documentation/ABI/testing/sysfs-driver-ppi | 2 +-
Documentation/ABI/testing/sysfs-driver-st | 2 +-
Documentation/ABI/testing/sysfs-driver-wacom | 2 +-
Documentation/Kconfig | 11 +
Documentation/Makefile | 5 +
Documentation/admin-guide/abi-obsolete.rst | 10 +
Documentation/admin-guide/abi-removed.rst | 4 +
Documentation/admin-guide/abi-stable.rst | 13 +
Documentation/admin-guide/abi-testing.rst | 19 +
Documentation/admin-guide/abi.rst | 11 +
Documentation/admin-guide/index.rst | 1 +
Documentation/conf.py | 2 +-
Documentation/sphinx/kernel_abi.py | 164 ++++++
lib/Kconfig.debug | 2 +
scripts/get_abi.pl | 475 ++++++++++++++++++
22 files changed, 753 insertions(+), 38 deletions(-)
create mode 100644 Documentation/Kconfig
create mode 100644 Documentation/admin-guide/abi-obsolete.rst
create mode 100644 Documentation/admin-guide/abi-removed.rst
create mode 100644 Documentation/admin-guide/abi-stable.rst
create mode 100644 Documentation/admin-guide/abi-testing.rst
create mode 100644 Documentation/admin-guide/abi.rst
create mode 100644 Documentation/sphinx/kernel_abi.py
create mode 100755 scripts/get_abi.pl
--
2.21.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox