* Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
From: Stephen Boyd @ 2019-08-12 23:59 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, mcgrof,
peterz, robh, shuah, tytso, yamada.masahiro, devicetree,
dri-devel, kunit-dev, linux-doc, linux-fsdevel, linux-kbuild,
linux-kernel, linux-kselftest, linux-nvdimm, linux-um,
Alexander.Levin, Tim.Bird, amir73il, dan.carpenter, daniel, jdike,
joel, julia.lawall, khilman, knut.omang, logang, mpe, pmladek,
rdunlap, richard, rientjes, rostedt, wfg
In-Reply-To: <20190812233336.GA224410@google.com>
Quoting Brendan Higgins (2019-08-12 16:33:36)
> On Mon, Aug 12, 2019 at 03:55:19PM -0700, Stephen Boyd wrote:
> > Quoting Brendan Higgins (2019-08-12 11:24:06)
> > > +void string_stream_clear(struct string_stream *stream)
> > > +{
> > > + struct string_stream_fragment *frag_container, *frag_container_safe;
> > > +
> > > + spin_lock(&stream->lock);
> > > + list_for_each_entry_safe(frag_container,
> > > + frag_container_safe,
> > > + &stream->fragments,
> > > + node) {
> > > + list_del(&frag_container->node);
> >
> > Shouldn't we free the allocation here? Otherwise, if some test is going
> > to add, add, clear, add, it's going to leak until the test is over?
>
> So basically this means I should add a kunit_kfree and
> kunit_resource_destroy (respective equivalents to devm_kfree, and
> devres_destroy) and use kunit_kfree here?
>
Yes, or drop the API entirely? Does anything need this functionality?
^ permalink raw reply
* Re: [PATCH v12 07/18] kunit: test: add initial tests
From: Stephen Boyd @ 2019-08-12 23:59 UTC (permalink / raw)
To: Brendan Higgins, frowand.list, gregkh, jpoimboe, keescook,
kieran.bingham, mcgrof, peterz, robh, shuah, tytso,
yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
In-Reply-To: <20190812182421.141150-8-brendanhiggins@google.com>
Quoting Brendan Higgins (2019-08-12 11:24:10)
> Add a test for string stream along with a simpler example.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* Re: [PATCH v12 05/18] kunit: test: add the concept of expectations
From: Stephen Boyd @ 2019-08-12 23:57 UTC (permalink / raw)
To: Brendan Higgins, frowand.list, gregkh, jpoimboe, keescook,
kieran.bingham, mcgrof, peterz, robh, shuah, tytso,
yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
In-Reply-To: <20190812182421.141150-6-brendanhiggins@google.com>
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@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.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?
>
> 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?
> +
> +/**
> + * 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.
> +
> +#define KUNIT_EXPECT_TRUE_MSG(test, condition, fmt, ...) \
> + KUNIT_TRUE_MSG_ASSERTION(test, \
> + KUNIT_EXPECTATION, \
> + condition, \
> + fmt, \
> + ##__VA_ARGS__)
> +
^ permalink raw reply
* Re: [PATCH v12 04/18] kunit: test: add assertion printing library
From: Brendan Higgins @ 2019-08-12 23:56 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: <20190812234644.E054D20679@mail.kernel.org>
On Mon, Aug 12, 2019 at 4:46 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-08-12 11:24:07)
> > Add `struct kunit_assert` and friends which provide a structured way to
> > capture data from an expectation or an assertion (introduced later in
> > the series) so that it may be printed out in the event of a failure.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > ---
>
> Reviewed-by: Stephen Boyd <sboyd@kernel.org>
>
> Just some minor nits below
>
> > diff --git a/include/kunit/assert.h b/include/kunit/assert.h
> > new file mode 100644
> > index 0000000000000..55f1b88b0cb4d
> > --- /dev/null
> > +++ b/include/kunit/assert.h
> > @@ -0,0 +1,183 @@
> [...]
> > + struct string_stream *stream);
> > +
> > +struct kunit_fail_assert {
> > + struct kunit_assert assert;
> > +};
> > +
> > +void kunit_fail_assert_format(const struct kunit_assert *assert,
> > + struct string_stream *stream);
> > +
> > +#define KUNIT_INIT_FAIL_ASSERT_STRUCT(test, type) { \
> > + .assert = KUNIT_INIT_ASSERT_STRUCT(test, \
> > + type, \
> > + kunit_fail_assert_format) \
>
> This one got indented one too many times?
Not unless I have been using the wrong formatting for multiline
macros. You can see this commit applied here:
https://kunit.googlesource.com/linux/+/870964da2990920030990dd1ffb647ef408e52df/include/kunit/assert.h#59
I have test, type, and kunit_fail_assert_format all column aligned (it
just doesn't render nicely in the patch format).
> > +}
> > +
> > +struct kunit_unary_assert {
> > + struct kunit_assert assert;
> > + const char *condition;
> > + bool expected_true;
> > +};
> > +
> > +void kunit_unary_assert_format(const struct kunit_assert *assert,
> > + struct string_stream *stream);
> > +
> [...]
> > +#define KUNIT_INIT_BINARY_STR_ASSERT_STRUCT(test, \
> > + type, \
> > + op_str, \
> > + left_str, \
> > + left_val, \
> > + right_str, \
> > + right_val) { \
> > + .assert = KUNIT_INIT_ASSERT_STRUCT(test, \
> > + type, \
> > + kunit_binary_str_assert_format), \
> > + .operation = op_str, \
> > + .left_text = left_str, \
> > + .left_value = left_val, \
> > + .right_text = right_str, \
> > + .right_value = right_val \
> > +}
>
> It would be nice to have kernel doc on these macros so we know how to
> use them.
Sounds good. Will fix.
^ permalink raw reply
* Re: [PATCH v12 04/18] kunit: test: add assertion printing library
From: Stephen Boyd @ 2019-08-12 23:46 UTC (permalink / raw)
To: Brendan Higgins, frowand.list, gregkh, jpoimboe, keescook,
kieran.bingham, mcgrof, peterz, robh, shuah, tytso,
yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
In-Reply-To: <20190812182421.141150-5-brendanhiggins@google.com>
Quoting Brendan Higgins (2019-08-12 11:24:07)
> Add `struct kunit_assert` and friends which provide a structured way to
> capture data from an expectation or an assertion (introduced later in
> the series) so that it may be printed out in the event of a failure.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Just some minor nits below
> diff --git a/include/kunit/assert.h b/include/kunit/assert.h
> new file mode 100644
> index 0000000000000..55f1b88b0cb4d
> --- /dev/null
> +++ b/include/kunit/assert.h
> @@ -0,0 +1,183 @@
[...]
> + struct string_stream *stream);
> +
> +struct kunit_fail_assert {
> + struct kunit_assert assert;
> +};
> +
> +void kunit_fail_assert_format(const struct kunit_assert *assert,
> + struct string_stream *stream);
> +
> +#define KUNIT_INIT_FAIL_ASSERT_STRUCT(test, type) { \
> + .assert = KUNIT_INIT_ASSERT_STRUCT(test, \
> + type, \
> + kunit_fail_assert_format) \
This one got indented one too many times?
> +}
> +
> +struct kunit_unary_assert {
> + struct kunit_assert assert;
> + const char *condition;
> + bool expected_true;
> +};
> +
> +void kunit_unary_assert_format(const struct kunit_assert *assert,
> + struct string_stream *stream);
> +
[...]
> +#define KUNIT_INIT_BINARY_STR_ASSERT_STRUCT(test, \
> + type, \
> + op_str, \
> + left_str, \
> + left_val, \
> + right_str, \
> + right_val) { \
> + .assert = KUNIT_INIT_ASSERT_STRUCT(test, \
> + type, \
> + kunit_binary_str_assert_format), \
> + .operation = op_str, \
> + .left_text = left_str, \
> + .left_value = left_val, \
> + .right_text = right_str, \
> + .right_value = right_val \
> +}
It would be nice to have kernel doc on these macros so we know how to
use them.
^ permalink raw reply
* Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
From: Brendan Higgins @ 2019-08-12 23:33 UTC (permalink / raw)
To: Stephen Boyd
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, mcgrof,
peterz, robh, shuah, tytso, yamada.masahiro, devicetree,
dri-devel, kunit-dev, linux-doc, linux-fsdevel, linux-kbuild,
linux-kernel, linux-kselftest, linux-nvdimm, linux-um,
Alexander.Levin, Tim.Bird, amir73il, dan.carpenter, daniel, jdike,
joel, julia.lawall, khilman, knut.omang, logang, mpe, pmladek,
rdunlap, richard, rientjes, rostedt, wfg
In-Reply-To: <20190812225520.5A67C206A2@mail.kernel.org>
On Mon, Aug 12, 2019 at 03:55:19PM -0700, Stephen Boyd wrote:
> Quoting Brendan Higgins (2019-08-12 11:24:06)
> > +void string_stream_clear(struct string_stream *stream)
> > +{
> > + struct string_stream_fragment *frag_container, *frag_container_safe;
> > +
> > + spin_lock(&stream->lock);
> > + list_for_each_entry_safe(frag_container,
> > + frag_container_safe,
> > + &stream->fragments,
> > + node) {
> > + list_del(&frag_container->node);
>
> Shouldn't we free the allocation here? Otherwise, if some test is going
> to add, add, clear, add, it's going to leak until the test is over?
So basically this means I should add a kunit_kfree and
kunit_resource_destroy (respective equivalents to devm_kfree, and
devres_destroy) and use kunit_kfree here?
> > + }
> > + stream->length = 0;
> > + spin_unlock(&stream->lock);
> > +}
> > +
^ permalink raw reply
* Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
From: Stephen Boyd @ 2019-08-12 22:55 UTC (permalink / raw)
To: Brendan Higgins, frowand.list, gregkh, jpoimboe, keescook,
kieran.bingham, mcgrof, peterz, robh, shuah, tytso,
yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
In-Reply-To: <20190812182421.141150-4-brendanhiggins@google.com>
Quoting Brendan Higgins (2019-08-12 11:24:06)
> +void string_stream_clear(struct string_stream *stream)
> +{
> + struct string_stream_fragment *frag_container, *frag_container_safe;
> +
> + spin_lock(&stream->lock);
> + list_for_each_entry_safe(frag_container,
> + frag_container_safe,
> + &stream->fragments,
> + node) {
> + list_del(&frag_container->node);
Shouldn't we free the allocation here? Otherwise, if some test is going
to add, add, clear, add, it's going to leak until the test is over?
> + }
> + stream->length = 0;
> + spin_unlock(&stream->lock);
> +}
> +
^ permalink raw reply
* Re: [PATCH v12 02/18] kunit: test: add test resource management API
From: Stephen Boyd @ 2019-08-12 22:10 UTC (permalink / raw)
To: Brendan Higgins, frowand.list, gregkh, jpoimboe, keescook,
kieran.bingham, mcgrof, peterz, robh, shuah, tytso,
yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
In-Reply-To: <20190812182421.141150-3-brendanhiggins@google.com>
Quoting Brendan Higgins (2019-08-12 11:24:05)
> Create a common API for test managed resources like memory and test
> objects. A lot of times a test will want to set up infrastructure to be
> used in test cases; this could be anything from just wanting to allocate
> some memory to setting up a driver stack; this defines facilities for
> creating "test resources" which are managed by the test infrastructure
> and are automatically cleaned up at the conclusion of the test.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [PATCH v2] driver/core: Fix build error when SRCU and lockdep disabled
From: Joel Fernandes (Google) @ 2019-08-12 21:49 UTC (permalink / raw)
To: linux-kernel
Cc: Joel Fernandes (Google), kernel-team, kbuild test robot,
Greg Kroah-Hartman, Josh Triplett, Lai Jiangshan, linux-doc,
Mathieu Desnoyers, Paul E. McKenney, Rafael J. Wysocki, rcu,
Steven Rostedt
Check if lockdep lock checking is disabled. If so, then do not define
device_links_read_lock_held(). It is used only from places where lockdep
checking is enabled.
Also fix a bug where I was not checking dep_map. Previously, I did not
test !SRCU configs so this got missed. Now it is sorted.
Link: https://lore.kernel.org/lkml/201908080026.WSAFx14k%25lkp@intel.com/
Fixes: c9e4d3a2fee8 ("acpi: Use built-in RCU list checking for acpi_ioremaps list")
(Based on RCU's dev branch)
Cc: kernel-team@android.com
Cc: kbuild test robot <lkp@intel.com>,
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cc: Josh Triplett <josh@joshtriplett.org>,
Cc: Lai Jiangshan <jiangshanlai@gmail.com>,
Cc: linux-doc@vger.kernel.org,
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>,
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Cc: rcu@vger.kernel.org,
Cc: Steven Rostedt <rostedt@goodmis.org>,
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
drivers/base/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 32cf83d1c744..c22271577c84 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -97,10 +97,12 @@ void device_links_read_unlock(int not_used)
up_read(&device_links_lock);
}
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
int device_links_read_lock_held(void)
{
- return lock_is_held(&device_links_lock);
+ return lock_is_held(&(device_links_lock.dep_map));
}
+#endif
#endif /* !CONFIG_SRCU */
/**
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* Re: [PATCH] Documentation/arm/samsung-s3c24xx: Remove stray U+FEFF character to fix title
From: Jonathan Corbet @ 2019-08-12 21:26 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-doc, linux-arm-kernel, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190808164811.15645-1-j.neuschaefer@gmx.net>
On Thu, 8 Aug 2019 18:48:09 +0200
Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
> It seems a UTF-8 byte order mark (the least useful kind of BOM...) snuck
> into the file and broke Sphinx's detection of the title line.
>
> Besides making arm/samsung-s3c24xx/index.html look a little better, this
> patch also confines the non-index pages in arm/samsung-s3c24xx to their
> own table of contents.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 2/2] Documentation/arm/sa1100/assabet: Fix 'make assabet_defconfig' command
From: Jonathan Corbet @ 2019-08-12 21:25 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-doc, linux-arm-kernel, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190808165929.16946-2-j.neuschaefer@gmx.net>
On Thu, 8 Aug 2019 18:58:56 +0200
Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
> "make assabet_config" doesn't work.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
> Documentation/arm/sa1100/assabet.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arm/sa1100/assabet.rst
> index 3e704831c311..a761e128fb08 100644
> --- a/Documentation/arm/sa1100/assabet.rst
> +++ b/Documentation/arm/sa1100/assabet.rst
> @@ -14,7 +14,7 @@ Building the kernel
>
> To build the kernel with current defaults::
>
> - make assabet_config
> + make assabet_defconfig
> make oldconfig
> make zImage
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 2/3] doc: Update documentation about list_for_each_entry_rcu (v1)
From: Paul E. McKenney @ 2019-08-12 21:24 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Greg Kroah-Hartman, Jonathan Corbet, Josh Triplett,
Lai Jiangshan, linux-doc, Mathieu Desnoyers, Rafael J. Wysocki,
rcu, Steven Rostedt, Tejun Heo
In-Reply-To: <20190812204205.GA48751@google.com>
On Mon, Aug 12, 2019 at 04:42:05PM -0400, Joel Fernandes wrote:
> On Mon, Aug 12, 2019 at 01:22:41PM -0700, Paul E. McKenney wrote:
> > On Sun, Aug 11, 2019 at 06:11:10PM -0400, Joel Fernandes (Google) wrote:
> > > This patch updates the documentation with information about
> > > usage of lockdep with list_for_each_entry_rcu().
> > >
> > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> >
> > Thank you!!!
> >
> > I queued this for v5.5 with the following wordsmithing. Please check
> > to make sure that I didn't mess anything up.
>
> Yes, this looks great to me. thanks!
>
> Also, I will send out the other drivers/core patch of this series in a bit
> with Steve's suggestion.
Very good! I do need acks from maintainers before sending these upstream,
though.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/arm/sa1100: Remove some obsolete documentation
From: Jonathan Corbet @ 2019-08-12 21:22 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-doc, linux-arm-kernel, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190808165929.16946-1-j.neuschaefer@gmx.net>
On Thu, 8 Aug 2019 18:58:55 +0200
Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
> The support for the following boards, among others, was removed in 2004
> with commit "[ARM] Remove broken SA1100 machine support.":
>
> - ADS Bitsy
> - Brutus
> - Freebird
> - ADS GraphicsClient Plus
> - ADS GraphicsMaster
> - Höft & Wessel Webpanel
> - Compaq Itsy
> - nanoEngine
> - Pangolin
> - PLEB
> - Yopy
>
> Tifon support has been removed in 2.4.3.3.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Well, you know, we don't like to be too hasty about such things...:)
Applied, thanks for helping to clean out some of the cobwebs!
jon
^ permalink raw reply
* Re: [PATCH v2] docs/zh_CN: update Chinese howto.rst for latexdocs making
From: Jonathan Corbet @ 2019-08-12 21:17 UTC (permalink / raw)
To: Alex Shi; +Cc: Harry Wei, Federico Vaga, SeongJae Park, Tom Levy, linux-doc
In-Reply-To: <20190809120447.22921-1-alex.shi@linux.alibaba.com>
On Fri, 9 Aug 2019 20:04:47 +0800
Alex Shi <alex.shi@linux.alibaba.com> wrote:
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> found a reference
> error in Chinese howto.rst. and further more there more infos of
> latexdocs/epubdocs format doc making in English howto.rst.
>
> So I update this part according to latest howto.rst and settled
> the correct reference.
>
> Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] Documentation: virt: Fix broken reference to virt tree's index
From: Jonathan Corbet @ 2019-08-12 21:16 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, linux-kernel-mentees, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau,
Song Liu, Yonghong Song, open list:DOCUMENTATION, open list,
open list:RISC-V ARCHITECTURE,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools)
In-Reply-To: <20190809132349.GA15460@localhost>
On Fri, 9 Aug 2019 14:23:49 +0100
Sheriff Esseson <sheriffesseson@gmail.com> wrote:
> Fix broken reference to virt/index.rst.
>
> Fixes: 2f5947dfcaec ("Documentation: move Documentation/virtual to
> Documentation/virt")
>
> Signed-off-by: Sheriff Esseson <sheriffesseson@gmail.com>
Note that you should keep the "Fixes:" tag on a single line, and not put a
blank line between it and the other tags. I've fixed that up and applied
the patch, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: Fix typo on pull requests guide
From: Jonathan Corbet @ 2019-08-12 21:13 UTC (permalink / raw)
To: Marco Villegas; +Cc: linux-doc, linux-kernel
In-Reply-To: <20190809232907.5432-1-git@marvil07.net>
On Fri, 9 Aug 2019 18:29:07 -0500
Marco Villegas <git@marvil07.net> wrote:
> Signed-off-by: Marco Villegas <git@marvil07.net>
> ---
> Documentation/maintainer/pull-requests.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst
> index 22b271de0304..1a2f99b67d25 100644
> --- a/Documentation/maintainer/pull-requests.rst
> +++ b/Documentation/maintainer/pull-requests.rst
> @@ -29,7 +29,7 @@ request to.
> In order to create the pull request you must first tag the branch that you
> have just created. It is recommended that you choose a meaningful tag name,
> in a way that you and others can understand, even after some time. A good
> -practice is to include in the name an indicator of the sybsystem of origin
> +practice is to include in the name an indicator of the subsystem of origin
> and the target kernel version.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v1] kernel-doc: Allow anonymous enum
From: Jonathan Corbet @ 2019-08-12 21:13 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-doc, Mika Westerberg, Linus Walleij
In-Reply-To: <20190812160631.32844-1-andriy.shevchenko@linux.intel.com>
On Mon, 12 Aug 2019 19:06:31 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> In C is a valid construction to have an anonymous enumerator.
>
> Though we have now:
>
> drivers/pinctrl/intel/pinctrl-intel.c:240: error: Cannot parse enum!
>
> Support it in the kernel-doc script.
So I don't get this error; I guess the only anonymous enum of interest has
yet to find its way into the mainline.
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> scripts/kernel-doc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 6b03012750da..079502bcc5a3 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1245,7 +1245,7 @@ sub dump_enum($$) {
> # strip #define macros inside enums
> $x =~ s@#\s*((define|ifdef)\s+|endif)[^;]*;@@gos;
>
> - if ($x =~ /enum\s+(\w+)\s*\{(.*)\}/) {
> + if ($x =~ /enum\s+(\w*)\s*\{(.*)\}/) {
Ah the joy of regexes...
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-08-12 21:12 UTC (permalink / raw)
To: John Ogness
Cc: Petr Mladek, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, Stephen Boyd, shuah, wfg, Greg KH,
Julia Lawall, linux-nvdimm, dri-devel, linux-um, Sasha Levin,
Theodore Ts'o, Richard Weinberger, Dan Carpenter, Knut Omang,
Josh Poimboeuf, Masahiro Yamada, Timothy Bird, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <871ry4yq3y.fsf@linutronix.de>
On Fri, Aug 02, 2019 at 09:37:53AM +0200, John Ogness wrote:
> On 2019-08-01, Brendan Higgins <brendanhiggins@google.com> wrote:
> > On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek <pmladek@suse.com> wrote:
> >> On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
> >>> On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek <pmladek@suse.com> wrote:
> >>>> On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> >>>>> Quoting Brendan Higgins (2019-07-22 15:30:49)
> >>>>>> On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >>>>>>> What's the calling context of the assertions and expectations? I
> >>>>>>> still don't like the fact that string stream needs to allocate
> >>>>>>> buffers and throw them into a list somewhere because the calling
> >>>>>>> context matters there.
> >>>>>>
> >>>>>> The calling context is the same as before, which is anywhere.
> >>>>>
> >>>>> Ok. That's concerning then.
> >>>>>
> >>>>>>> I'd prefer we just wrote directly to the console/log via printk
> >>>>>>> instead. That way things are simple because we use the existing
> >>>>>>> buffering path of printk, but maybe there's some benefit to the
> >>>>>>> string stream that I don't see? Right now it looks like it
> >>>>>>> builds a string and then dumps it to printk so I'm sort of lost
> >>>>>>> what the benefit is over just writing directly with printk.
> >>>>>>
> >>>>>> It's just buffering it so the whole string gets printed
> >>>>>> uninterrupted. If we were to print out piecemeal to printk,
> >>>>>> couldn't we have another call to printk come in causing it to
> >>>>>> garble the KUnit message we are in the middle of printing?
> >>>>>
> >>>>> Yes, printing piecemeal by calling printk many times could lead to
> >>>>> interleaving of messages if something else comes in such as an
> >>>>> interrupt printing something. Printk has some support to hold
> >>>>> "records" but I'm not sure how that would work here because
> >>>>> KERN_CONT talks about only being used early on in boot code. I
> >>>>> haven't looked at printk in detail though so maybe I'm all wrong
> >>>>> and KERN_CONT just works?
> >>>>
> >>>> KERN_CONT does not guarantee that the message will get printed
> >>>> together. The pieces get interleaved with messages printed in
> >>>> parallel.
> >>>>
> >>>> Note that KERN_CONT was originally really meant to be used only
> >>>> during boot. It was later used more widely and ended in the best
> >>>> effort category.
> >>>>
> >>>> There were several attempts to make it more reliable. But it was
> >>>> always either too complicated or error prone or both.
> >>>>
> >>>> You need to use your own buffering if you rely want perfect output.
> >>>> The question is if it is really worth the complexity. Also note
> >>>> that any buffering reduces the chance that the messages will reach
> >>>> the console.
> >>>
> >>> Seems like that settles it then. Thanks!
> >>>
> >>>> BTW: There is a work in progress on a lockless printk ring buffer.
> >>>> It will make printk() more secure regarding deadlocks. But it might
> >>>> make transparent handling of continuous lines even more tricky.
> >>>>
> >>>> I guess that local buffering, before calling printk(), will be
> >>>> even more important then. Well, it might really force us to create
> >>>> an API for it.
> >>>
> >>> Cool! Can you CC me on that discussion?
> >>
> >> Adding John Oggness into CC.
> >>
> >> John, please CC Brendan Higgins on the patchsets eventually switching
> >> printk() into the lockless buffer. The test framework is going to
> >> do its own buffering to keep the related messages together.
> >>
> >> The lockless ringbuffer might make handling of related (partial)
> >> lines worse or better. It might justify KUnit's extra buffering
> >> or it might allow to get rid of it.
> >
> > Thanks for CC'ing me on the printk ringbuffer thread. It looks like it
> > actually probably won't affect my needs for KUnit logging. The biggest
> > reason I need some sort of buffering system is to be able to compose
> > messages piece meal into a single message that will be printed out to
> > the user as a single message with no messages from other printk
> > callers printed out in the middle of mine.
>
> printk has this same requirement for its CONT messages. You can read
> about how I propose to implement that here[0], using a separate prb
> ringbuffer for buffered storage until all the pieces are available.
>
> It is not my goal that multiple subsystems start making use of the prb
> ringbuffer. However, its features can be attractive if you don't want to
> worry about multiple writers/readers or context (including NMI). Before
That sounds like it might be useful down the road, but not to replace
the string_stream.
> writing "yet another ringbuffer" [1] it might be worth the effort to at
> least see if one of the existing implementations can work (or be
> extended to work) for you.
In regards to the conversation here about string_stream/kunit_stream, I
think Petr already answered that question. As I said previously:
> [I]t appears that to get the
> semantics that I need, I would have to put my entire message in a
> single data block and would consequently need to know the size of my
> message a priori, which is problematic. Consequently, it seems as
> though I will probably need to compose my entire message using my own
> buffering system.
I could potentially use my own set of prbs for that buffering; however,
I think this use case is probably closer to seq_buf than your prb.
Really, I just want some kind of string builder, not a message queue.
The place where I think your prb is relevant here is once I have
composed the message and I just want to print it, having a way to print
it without worrying about context is nice, but I think that is a
separate discussion from the main topic here which was just figuring out
the right way to compose that message in the first place.
Cheers
> John Ogness
>
> [0] https://lkml.kernel.org/r/87imt2bl0k.fsf@linutronix.de
> [1] https://lwn.net/Articles/789603/
>
> > The prb does look interesting; however, it appears that to get the
> > semantics that I need, I would have to put my entire message in a
> > single data block and would consequently need to know the size of my
> > message a priori, which is problematic. Consequently, it seems as
> > though I will probably need to compose my entire message using my own
> > buffering system.
> >
> >>>> Note that stroring the messages into the printk log is basically
> >>>> safe in any context. It uses temporary per-CPU buffers for
> >>>> recursive messages and in NMI. The only problem is panic() when
> >>>> some CPU gets stuck with the lock taken. This will get solved by
> >>>> the lockless ringbuffer. Also the temporary buffers will not be
> >>>> necessary any longer.
> >>>
> >>> Sure, I think Stephen's concern is all the supporting code that is
> >>> involved. Not printk specifically. It just means a lot more of KUnit
> >>> has to be IRQ safe.
> >>
> >> I see.
> >>
> >> BTW: I wonder if KUnit could reuse the existing seq_buf
> >> implementation for buffering messages.
> >>
> >> I am sorry if it has already been proposed and rejected for some
> >> reason. I might have missed it. Feel free to just point me to
> >> same older mail.
> >
> > Yeah, we discussed it briefly here:
> >
> > https://lkml.org/lkml/2019/5/17/497
> >
> > Looks like I forgot to include my reasoning in the commit text, sorry
> > about that.
> >
> >>>> Much bigger problems are with consoles. There are many of them. It
> >>>> means a lot of code and more locks involved, including scheduler
> >>>> locks. Note that console lock is a semaphore.
> >>>
> >>> That shouldn't affect us though, right? As long as we continue to
> >>> use the printk interface?
> >>
> >> I guess that it should not affect KUnit.
> >>
> >> The only problem might be if the testing framework calls printk()
> >> inside scheduler or console code. And only when the tested code
> >> uses the same locks that will be used by the called printk().
> >
> > Yeah, well printk will not be our only problem in those instances.
> >
> >> To be honest I do not fully understand KUnit design. I am not
> >> completely sure how the tested code is isolated from the running
> >> system. Namely, I do not know if the tested code shares
> >> the same locks with the system running the test.
> >
> > No worries, I don't expect printk to be the hang up in those cases. It
> > sounds like KUnit has a long way to evolve before printk is going to
> > be a limitation.
> >
> > Thanks!
^ permalink raw reply
* Re: [PATCH v2 1/2] Documentation: sphinx: Add missing comma to list of strings
From: Jonathan Corbet @ 2019-08-12 20:56 UTC (permalink / raw)
To: Jonathan Neuschäfer; +Cc: linux-doc, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190812160708.32172-1-j.neuschaefer@gmx.net>
On Mon, 12 Aug 2019 18:07:04 +0200
Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
> In Python, like in C, when a comma is omitted in a list of strings, the
> two strings around the missing comma are concatenated.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
>
> v2:
> - new patch
> ---
> Documentation/sphinx/automarkup.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py
> index 77e89c1956d7..a8798369e8f7 100644
> --- a/Documentation/sphinx/automarkup.py
> +++ b/Documentation/sphinx/automarkup.py
> @@ -25,7 +25,7 @@ RE_function = re.compile(r'([\w_][\w\d_]+\(\))')
> # to the creation of incorrect and confusing cross references. So
> # just don't even try with these names.
> #
> -Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap'
> +Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap',
> 'select', 'poll', 'fork', 'execve', 'clone', 'ioctl']
Hmm...that's a wee bit embarrassing. Applied (and the socket() patch
too), thanks.
jon
^ permalink raw reply
* Re: [PATCH 2/3] doc: Update documentation about list_for_each_entry_rcu (v1)
From: Joel Fernandes @ 2019-08-12 20:42 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Greg Kroah-Hartman, Jonathan Corbet, Josh Triplett,
Lai Jiangshan, linux-doc, Mathieu Desnoyers, Rafael J. Wysocki,
rcu, Steven Rostedt, Tejun Heo
In-Reply-To: <20190812202241.GP28441@linux.ibm.com>
On Mon, Aug 12, 2019 at 01:22:41PM -0700, Paul E. McKenney wrote:
> On Sun, Aug 11, 2019 at 06:11:10PM -0400, Joel Fernandes (Google) wrote:
> > This patch updates the documentation with information about
> > usage of lockdep with list_for_each_entry_rcu().
> >
> > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
>
> Thank you!!!
>
> I queued this for v5.5 with the following wordsmithing. Please check
> to make sure that I didn't mess anything up.
Yes, this looks great to me. thanks!
Also, I will send out the other drivers/core patch of this series in a bit
with Steve's suggestion.
- Joel
[snip]
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-08-12 20:41 UTC (permalink / raw)
To: Stephen Boyd
Cc: Petr Mladek, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, shuah, wfg, Greg KH, Julia Lawall,
linux-nvdimm, dri-devel, linux-um, Sasha Levin, Theodore Ts'o,
Richard Weinberger, Dan Carpenter, Knut Omang, Josh Poimboeuf,
Masahiro Yamada, Timothy Bird, John Ogness, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAFd5g47tk8x5iet=xfPVO6MphD3SsLtYQLrCi5O2h0bvdXwHtA@mail.gmail.com>
On Thu, Aug 1, 2019 at 2:43 PM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Thu, Aug 1, 2019 at 2:14 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Brendan Higgins (2019-08-01 11:59:57)
> > > On Thu, Aug 1, 2019 at 11:55 AM Brendan Higgins
> > > <brendanhiggins@google.com> wrote:
> > > >
> > > > On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek <pmladek@suse.com> wrote:
> > > >
> > > > > To be honest I do not fully understand KUnit design. I am not
> > > > > completely sure how the tested code is isolated from the running
> > > > > system. Namely, I do not know if the tested code shares
> > > > > the same locks with the system running the test.
> > > >
> > > > No worries, I don't expect printk to be the hang up in those cases. It
> > > > sounds like KUnit has a long way to evolve before printk is going to
> > > > be a limitation.
> > >
> > > So Stephen, what do you think?
> > >
> > > Do you want me to go forward with the new kunit_assert API wrapping
> > > the string_stream as I have it now? Would you prefer to punt this to a
> > > later patch? Or would you prefer something else?
> > >
> >
> > I like the struct based approach. If anything, it can be adjusted to
> > make the code throw some records into a spinlock later on and delay the
> > formatting of the assertion if need be.
>
> That's a fair point.
>
> > Can you resend with that
> > approach? I don't think I'll have any more comments after that.
I sent a new revision, v12, that incorporates the kunit_assert stuff.
Let me know what you think!
^ permalink raw reply
* Re: [PATCH 2/3] doc: Update documentation about list_for_each_entry_rcu (v1)
From: Paul E. McKenney @ 2019-08-12 20:22 UTC (permalink / raw)
To: Joel Fernandes (Google)
Cc: linux-kernel, Greg Kroah-Hartman, Jonathan Corbet, Josh Triplett,
Lai Jiangshan, linux-doc, Mathieu Desnoyers, Rafael J. Wysocki,
rcu, Steven Rostedt, Tejun Heo
In-Reply-To: <20190811221111.99401-2-joel@joelfernandes.org>
On Sun, Aug 11, 2019 at 06:11:10PM -0400, Joel Fernandes (Google) wrote:
> This patch updates the documentation with information about
> usage of lockdep with list_for_each_entry_rcu().
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Thank you!!!
I queued this for v5.5 with the following wordsmithing. Please check
to make sure that I didn't mess anything up.
Thanx, Paul
------------------------------------------------------------------------
commit d06933df6b5919abfd298291f2a6b0a3a095ae64
Author: Joel Fernandes (Google) <joel@joelfernandes.org>
Date: Sun Aug 11 18:11:10 2019 -0400
doc: Update list_for_each_entry_rcu() documentation
This commit updates the documentation with information about
usage of lockdep with list_for_each_entry_rcu().
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[ paulmck: Wordsmithing. ]
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt
index da51d3068850..89db949eeca0 100644
--- a/Documentation/RCU/lockdep.txt
+++ b/Documentation/RCU/lockdep.txt
@@ -96,7 +96,17 @@ other flavors of rcu_dereference(). On the other hand, it is illegal
to use rcu_dereference_protected() if either the RCU-protected pointer
or the RCU-protected data that it points to can change concurrently.
-There are currently only "universal" versions of the rcu_assign_pointer()
-and RCU list-/tree-traversal primitives, which do not (yet) check for
-being in an RCU read-side critical section. In the future, separate
-versions of these primitives might be created.
+Like rcu_dereference(), when lockdep is enabled, RCU list and hlist
+traversal primitives check for being called from within an RCU read-side
+critical section. However, a lockdep expression can be passed to them
+as a additional optional argument. With this lockdep expression, these
+traversal primitives will complain only if the lockdep expression is
+false and they are called from outside any RCU read-side critical section.
+
+For example, the workqueue for_each_pwq() macro is intended to be used
+either within an RCU read-side critical section or with wq->mutex held.
+It is thus implemented as follows:
+
+ #define for_each_pwq(pwq, wq)
+ list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node,
+ lock_is_held(&(wq->mutex).dep_map))
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 17f48319ee16..58ba05c4d97f 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -290,7 +290,7 @@ rcu_dereference()
at any time, including immediately after the rcu_dereference().
And, again like rcu_assign_pointer(), rcu_dereference() is
typically used indirectly, via the _rcu list-manipulation
- primitives, such as list_for_each_entry_rcu().
+ primitives, such as list_for_each_entry_rcu() [2].
[1] The variant rcu_dereference_protected() can be used outside
of an RCU read-side critical section as long as the usage is
@@ -305,6 +305,14 @@ rcu_dereference()
a lockdep splat is emitted. See Documentation/RCU/Design/Requirements/Requirements.rst
and the API's code comments for more details and example usage.
+ [2] If the list_for_each_entry_rcu() instance might be used by
+ update-side code as well as by RCU readers, then an additional
+ lockdep expression can be added to its list of arguments.
+ For example, given an additional "lock_is_held(&mylock)" argument,
+ the RCU lockdep code would complain only if this instance was
+ invoked outside of an RCU read-side critical section and without
+ the protection of mylock.
+
The following diagram shows how each API communicates among the
reader, updater, and reclaimer.
^ permalink raw reply related
* Re: [PATCH 3/3] driver/core: Fix build error when SRCU and lockdep disabled
From: Steven Rostedt @ 2019-08-12 20:05 UTC (permalink / raw)
To: Joel Fernandes
Cc: Greg Kroah-Hartman, linux-kernel, kbuild test robot,
Jonathan Corbet, Josh Triplett, Lai Jiangshan, linux-doc,
Mathieu Desnoyers, Paul E. McKenney, Rafael J. Wysocki, rcu,
Tejun Heo
In-Reply-To: <20190812200125.GA161786@google.com>
On Mon, 12 Aug 2019 16:01:25 -0400
Joel Fernandes <joel@joelfernandes.org> wrote:
> > some/header/file.h:
> >
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() WARN_ON_ONCE(!defice_links_read_lock_held())
> > #else
> > # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() do { } while (0)
> > #endif
> >
> > And just use CHECK_DEVICE_LINK_READ_LOCK_HELD() in those places. I
> > agree with Greg. "device_links_read_lock_heald()" should *never*
> > blindly return 1. It's confusing.
>
> Ok, then I will update the patch to do:
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> int device_links_read_lock_held(void)
> {
> return lock_is_held(&device_links_lock);
> }
> #endif
>
> That will also solve the build error. And callers can follow the above pattern you shared.
Sounds good!
-- Steve
^ permalink raw reply
* Re: [PATCH 3/3] driver/core: Fix build error when SRCU and lockdep disabled
From: Joel Fernandes @ 2019-08-12 20:01 UTC (permalink / raw)
To: Steven Rostedt
Cc: Greg Kroah-Hartman, linux-kernel, kbuild test robot,
Jonathan Corbet, Josh Triplett, Lai Jiangshan, linux-doc,
Mathieu Desnoyers, Paul E. McKenney, Rafael J. Wysocki, rcu,
Tejun Heo
In-Reply-To: <20190812141119.6ec00a34@gandalf.local.home>
On Mon, Aug 12, 2019 at 02:11:19PM -0400, Steven Rostedt wrote:
> On Mon, 12 Aug 2019 09:03:10 -0400
> Joel Fernandes <joel@joelfernandes.org> wrote:
>
>
> > > > drivers/base/core.c | 6 +++++-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > > index 32cf83d1c744..fe25cf690562 100644
> > > > --- a/drivers/base/core.c
> > > > +++ b/drivers/base/core.c
> > > > @@ -99,7 +99,11 @@ void device_links_read_unlock(int not_used)
> > > >
> > > > int device_links_read_lock_held(void)
> > > > {
> > > > - return lock_is_held(&device_links_lock);
> > > > +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > > + return lock_is_held(&(device_links_lock.dep_map));
> > > > +#else
> > > > + return 1;
> > > > +#endif
> > >
> > > return 1? So the lock is always held?
>
> I was thinking the exact same thing.
>
> >
> > This is just the pattern of an assert that is disabled, so that
> > false-positives don't happen if lockdep is disabled.
> >
> > So say someone writes a statement like:
> > WARN_ON_ONCE(!device_links_read_lock_held());
> >
> > Since lockdep is disabled, we cannot check whether lock is held or not. Yet,
> > we don't want false positives by reporting that the lock is not held. In this
> > case, it is better to report that the lock is held to suppress
> > false-positives. srcu_read_lock_held() also follows the same pattern.
> >
>
> The real answer here is to make that WARN_ON_ONCE() dependent on
> lockdep. Something like:
>
>
> some/header/file.h:
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() WARN_ON_ONCE(!defice_links_read_lock_held())
> #else
> # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() do { } while (0)
> #endif
>
> And just use CHECK_DEVICE_LINK_READ_LOCK_HELD() in those places. I
> agree with Greg. "device_links_read_lock_heald()" should *never*
> blindly return 1. It's confusing.
Ok, then I will update the patch to do:
#ifdef CONFIG_DEBUG_LOCK_ALLOC
int device_links_read_lock_held(void)
{
return lock_is_held(&device_links_lock);
}
#endif
That will also solve the build error. And callers can follow the above pattern you shared.
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
From: Guenter Roeck @ 2019-08-12 19:33 UTC (permalink / raw)
To: John Wang
Cc: jdelvare, corbet, linux-hwmon, linux-doc, linux-kernel, miltonm,
Yu Lei, duanzhijia01, Joel Stanley, OpenBMC Maillist
In-Reply-To: <CAHkHK0_wts97mEjSOpZrKU8bTWKzh0+HBxTg0fSmdkFBsrWjFA@mail.gmail.com>
On Mon, Aug 12, 2019 at 12:48:34PM +0800, John Wang wrote:
>
> So I should
>
> 1. Add SENSOR_INSPUR_IPSPS to the end of the file
> 2. Add SENSOR_INSPUR_IPSPS in alphabetical order, without additional tab
> 3. other suggestions
>
I would suggest 2). Just use a space before += instead of a tab.
Guenter
^ 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