[Re: [PATCH] init: move THIS_MODULE from to ] On
03/12/2023 (Sun 19:06) Masahiro Yamada wrote:
> On Sun, Nov 26, 2023 at 4:19???PM Masahiro Yamada
> wrote:
> >
> > Commit f50169324df4 ("module.h: split out the EXPORT_SYMBOL into
> > export.h") appropriately separated EXPORT_SYMBOL into
> >
.
As shown above, with this change, RCU and nohz_full are in sync, even
with the use of the "N" placeholder. Same result is achieved with "15".
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Paul E. McKenney
Cc: Frederic Weisbecker
Signed-off-by: Paul Gortmaker
diff --git a/kernel/sched
recently as a year ago for as yet unseen new flags.
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Peter Xu
Fixes: 3662daf02350 ("sched/isolation: Allow "isolcpus=" to skip unknown
sub-parameters")
Signed-off-by: Paul Gortmaker
diff
Zijlstra
Cc: Frederic Weisbecker
Fixes: 3662daf02350 ("sched/isolation: Allow "isolcpus=" to skip unknown
sub-parameters")
Signed-off-by: Paul Gortmaker
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 5a6ea03f9882..9652dba7e938 100644
--- a/kernel/sched
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 3e70df91f961b9df7ab3c0ae1934bdf15454c536
Gitweb:
https://git.kernel.org/tip/3e70df91f961b9df7ab3c0ae1934bdf15454c536
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:27 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 494215fbf298787e4ead16e4c68634d241336b02
Gitweb:
https://git.kernel.org/tip/494215fbf298787e4ead16e4c68634d241336b02
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:20 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 6fef5905fbd691aeb91093056b27d5ee7b106097
Gitweb:
https://git.kernel.org/tip/6fef5905fbd691aeb91093056b27d5ee7b106097
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:21 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 97330db3af9a41302d1ccb0f495fcb5b5da2cc44
Gitweb:
https://git.kernel.org/tip/97330db3af9a41302d1ccb0f495fcb5b5da2cc44
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:22 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 9d7a3366b7028ae8dd16a0d7585cbf11b03b42a0
Gitweb:
https://git.kernel.org/tip/9d7a3366b7028ae8dd16a0d7585cbf11b03b42a0
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:23 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: f3c869caef648c541a7445f2a6ba2196d343f542
Gitweb:
https://git.kernel.org/tip/f3c869caef648c541a7445f2a6ba2196d343f542
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:24 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 2c4885d24e64941702a8f81c8e83289823ba35d0
Gitweb:
https://git.kernel.org/tip/2c4885d24e64941702a8f81c8e83289823ba35d0
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:25 -05:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 99c58d1adbca25fb3ee2469bf0904e1e3e021f7e
Gitweb:
https://git.kernel.org/tip/99c58d1adbca25fb3ee2469bf0904e1e3e021f7e
Author:Paul Gortmaker
AuthorDate:Sun, 21 Feb 2021 03:08:26 -05:00
on references
to it. The support itself needs to remain for now, since we don't
know how many people out there are using it currently, but since it
is in an __init area anyway, it isn't worth losing sleep over.
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Josh Triplett
ury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Suggested-by: Yury Norov # move it from CPU code
Signed-off-by: Paul Gortmaker
---
.../admin-guide/kernel-parameters.rst | 7 ++
lib/bitmap.c | 2
This will reduce parameter passing and enable using nbits as part
of future dynamic region parameter parsing.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Suggested-by: Yury Norov
Acked-by: Yury Norov
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c
These are copies of existing tests, with just 31 --> N. This ensures
the recently added "N" alias transparently works in any normally
numeric fields of a region specification.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_
Shevchenko
Acked-by: Yury Norov
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 162e2850c622..833f152a2c43 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
Add tests that specify a valid range, but one that is outside the
width of the bitmap for which it is to be applied to. These should
trigger an -ERANGE response from the code.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul Gortmaker
:
1) document what might seem odd but nonetheless valid input.
2) don't regress from what we currently accept as valid.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Acked-by: Yury Norov
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_bitmap.c | 22
"N" as per PeterZ.]
https://lore.kernel.org/lkml/20210121223355.59780-1-paul.gortma...@windriver.com/
[v1: https://lore.kernel.org/lkml/20210106004850.GA11682@paulmck-ThinkPad-P72/
Cc: Li Zefan
Cc: Ingo Molnar
Cc: Yury Norov
Cc: Thomas Gleixner
Cc: Josh Triplett
Cc: Peter Zijlstra
te them to 32 bit so it is clear what they are meant to target.
Then we can add tests specific for ERANGE (no syntax errors, just
doing 32bit op on 8 bit width, plus a typical 9-on-8 fencepost error).
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul
[Re: [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap] On
11/02/2021 (Thu 17:24) Yury Norov wrote:
> On Wed, Feb 10, 2021 at 06:49:30PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 10, 2021 at 10:58:25AM -0500, Paul Gortmaker wrote:
> > > [Re: [PAT
On Tue, Feb 09, 2021 at 05:58:59PM -0500, Paul Gortmaker wrote:
> > > > The basic objective here was to add support for "nohz_full=8-N" and/or
> > > > "rcu_nocbs="4-N" -- essentially introduce "N" as a portable reference
> > > >
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 9d3a04853fe640e0eba2c0799c880b7dcf190219
Gitweb:
https://git.kernel.org/tip/9d3a04853fe640e0eba2c0799c880b7dcf190219
Author:Paul Gortmaker
AuthorDate:Sat, 28 Nov 2020 15:32:59 -05:00
[Re: [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap] On
09/02/2021 (Tue 15:16) Yury Norov wrote:
> On Tue, Feb 9, 2021 at 3:01 PM Paul Gortmaker
> wrote:
[...]
> >
> > -static const char *bitmap_getnum(const char *str, unsigned int
ury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Suggested-by: Yury Norov # move it from CPU code
Signed-off-by: Paul Gortmaker
---
.../admin-guide/kernel-parameters.rst | 7 +
lib/bitmap.c | 2
lnar
Cc: Yury Norov
Cc: Thomas Gleixner
Cc: Josh Triplett
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Frederic Weisbecker
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Paul Gortmaker (8):
lib: test_bitmap: clearly separate ERANGE from EINVAL tests.
lib: test_bitmap: add tests to
Shevchenko
Acked-by: Yury Norov
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 75006c4036e9..9596ba53c36b 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -499,25 +499,22 @@ struct
These are copies of existing tests, with just 31 --> N. This ensures
the recently added "N" alias transparently works in any normally
numeric fields of a region specification.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_
.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Suggested-by: Yury Norov
Suggested-by: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index
on references
to it. The support itself needs to remain for now, since we don't
know how many people out there are using it currently, but since it
is in an __init area anyway, it isn't worth losing sleep over.
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Josh Triplett
te them to 32 bit so it is clear what they are meant to target.
Then we can add tests specific for ERANGE (no syntax errors, just
doing 32bit op on 8 bit width, plus a typical 9-on-8 fencepost error).
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul
:
1) document what might seem odd but nonetheless valid input.
2) don't regress from what we currently accept as valid.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Acked-by: Yury Norov
Reviewed-by: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_bitmap.c | 22
Add tests that specify a valid range, but one that is outside the
width of the bitmap for which it is to be applied to. These should
trigger an -ERANGE response from the code.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_bitmap.c | 2
[Re: [PATCH v3 0/8] support for bitmap (and hence CPU) list "N" abbreviation]
On 26/01/2021 (Tue 14:27) Yury Norov wrote:
> On Tue, Jan 26, 2021 at 9:12 AM Paul Gortmaker
> wrote:
> >
> > This was on a 16 core machine with CONFIG_NR_CPUS=16 in .config file.
> &
[Re: [PATCH 5/8] lib: bitmap_getnum: separate arg into region and field] On
26/01/2021 (Tue 18:58) Yury Norov wrote:
> On Tue, Jan 26, 2021 at 1:22 PM Andy Shevchenko
> wrote:
> >
> > On Tue, Jan 26, 2021 at 12:11:38PM -0500, Paul Gortmaker wrote:
> > > The
[Re: [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap] On
26/01/2021 (Tue 23:37) Andy Shevchenko wrote:
> On Tue, Jan 26, 2021 at 12:11:39PM -0500, Paul Gortmaker wrote:
> > While this is done for all bitmaps, the original use case in mind wa
[Re: [PATCH 3/8] lib: bitmap: fold nbits into region struct] On 26/01/2021 (Tue
23:16) Andy Shevchenko wrote:
> On Tue, Jan 26, 2021 at 12:11:36PM -0500, Paul Gortmaker wrote:
> > This will reduce parameter passing and enable using nbits as part
> > of future dynamic region pa
[Re: [PATCH 1/8] lib: test_bitmap: clearly separate ERANGE from EINVAL tests.]
On 26/01/2021 (Tue 23:04) Andy Shevchenko wrote:
> On Tue, Jan 26, 2021 at 12:11:34PM -0500, Paul Gortmaker wrote:
> > This block of tests was meant to find/flag incorrect use of the ":"
> > a
[Re: [PATCH 3/3] lib: support N as end of range in bitmap_parselist()] On
22/01/2021 (Fri 15:08) Yury Norov wrote:
> On Thu, Jan 21, 2021 at 8:44 PM Paul Gortmaker
> wrote:
> >
> > [Re: [PATCH 3/3] lib: support N as end of range in bitmap_parselist()] On
> > 21/01/202
These are copies of existing tests, with just 31 --> N. This ensures
the recently added "N" alias transparently works in any normally
numeric fields of a region specification.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_
ury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Suggested-by: Yury Norov
Signed-off-by: Paul Gortmaker
---
Documentation/admin-guide/kernel-parameters.rst | 2 ++
lib/bitmap.c| 12 ++--
2 file
on references
to it. The support itself needs to remain for now, since we don't
know how many people out there are using it currently, but since it
is in an __init area anyway, it isn't worth losing sleep over.
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Cc: Josh Triplett
The bitmap_getnum is only used on a region's start/end/off/group_len
field. Trivially decouple the region from the field so that the region
pointer is available for a pending change.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c | 9
:
1) document what might seem odd but nonetheless valid input.
2) don't regress from what we currently accept as valid.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_bitmap.c | 22 ++
1 file changed, 22 insertions
ot; vs.
just being allowed at end of range like "0-N". Add new self-tests. Drop
"all" and "none" aliases as redundant and not worth the extra complication. ]
Cc: Li Zefan
Cc: Ingo Molnar
Cc: Yury Norov
Cc: Thomas Gleixner
Cc: Josh Triplett
Cc: Peter Zijlstra
Cc:
Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 162e2850c622..833f152a2c43 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -500,17 +500,12 @@ struct region {
unsigned int
r->start > r->end) ---> EINVAL before we
check for (r->end >= nbits) ---> ERANGE. If the code is ever re-ordered
then this test will pick up the mismatched errno value.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/tes
This will reduce parameter passing and enable using nbits as part
of future dynamic region parameter parsing.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Suggested-by: Yury Norov
Signed-off-by: Paul Gortmaker
---
lib/bitmap.c | 19 ++-
1 file changed, 10
[Re: [PATCH 3/3] lib: support N as end of range in bitmap_parselist()] On
21/01/2021 (Thu 16:29) Yury Norov wrote:
> On Thu, Jan 21, 2021 at 2:34 PM Paul Gortmaker
> wrote:
> >
> > While this is done for all bitmaps, the original use case in mind was
> > for CPU
[Re: [PATCH 1/3] lib: add "all" and "none" as valid ranges to
bitmap_parselist()] On 21/01/2021 (Thu 16:07) Yury Norov wrote:
> On Thu, Jan 21, 2021 at 2:34 PM Paul Gortmaker
> wrote:
> >
> > The use of "all" was originally RCU specific - I'd pu
[Re: [PATCH RFC cpumask] Allow "all", "none", and "last" in cpumask strings] On
20/01/2021 (Wed 23:11) Yury Norov wrote:
> Hi Paul,
>
> Today I found this series in linux-next despite downsides discovered during
> the review. This series introduces absolutely unneeded cap on the number of
>
Now that the core bitmap parse code respects the "all" parameter, there
is no need for RCU to have its own special check for it.
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Signed-off-by: Paul Gortmaker
---
Documentation/admin-guide/kernel-parameters.txt |
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Signed-off-by: Paul Gortmaker
---
Documentation/admin-guide/kernel-parameters.rst | 11 +++
lib/bitmap.c| 9 +
2 files changed, 20 insertions(+)
diff --git a/Do
ore fencepost errors of using 32 and 48 instead of 31 and 47.
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Signed-off-by: Paul Gortmaker
---
.../admin-guide/kernel-parameters.rst | 4
lib/bitmap.c | 18 +-
2 file
down from cpu subsys to core bitmap code as per
Yury's comments. Change "last" to simply be "N" as per PeterZ.
Combination of the two got rid of needing strword() and greatly
reduced complexity and footprint of the change -- thanks! ]
Cc: Yury Norov
Cc: Peter Zijlstra
C
ory forever, for anyone who
happens to find a functional board and wants to tinker with it.
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Paul Gortmaker
---
arch/powerpc/boot/Makefile | 1 -
arch/powerpc/boot/dts/sbc8548-altflash.
git history forever, for anyone who
happens to find a functional board and wants to tinker with it.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Paul Gortmaker
---
arch/powerpc/boot/dts/fsl/sbc8641d.dts | 176 ---
arch/powerpc/conf
Signed-off-by: Paul Gortmaker
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cc1e6a5ee6e6..c5f5cdb24674 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6529,7 +6529,6 @@ F:Documentation/admin-guide/media/em28xx*
F: drivers/media/usb
git/paulg/linux.git wr_sbc-delete
for you to fetch changes up to 1dfb28199572e3f6517cada41f6a150551749da1:
MAINTAINERS: update for Paul Gortmaker (2021-01-11 00:06:01 -0500)
----
Paul Gortmaker (3):
powerpc: retire sbc8548 bo
l Deacon
Signed-off-by: Paul Gortmaker
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e30cf02da8b8..e2f9e6582a10 100644
--- a/Makefile
+++ b/Makefile
@@ -937,7 +937,7 @@ KBUILD_CFLAGS += -fno-stack-check
KBUILD_CFLAGS += $(call cc-opt
[Re: [PATCH RFC cpumask 4/5] cpumask: Add "last" alias for cpu list
specifications] On 06/01/2021 (Wed 10:49) Peter Zijlstra wrote:
> On Tue, Jan 05, 2021 at 04:49:55PM -0800, paul...@kernel.org wrote:
> > From: Paul Gortmaker
> >
> > It seems that a common
[Re: [PATCH 0/3] clear_warn_once: add timed interval resetting] On 09/12/2020
(Wed 17:37) Petr Mladek wrote:
> On Thu 2020-11-26 01:30:26, Paul Gortmaker wrote:
> > The existing clear_warn_once functionality is currently a manually
> > issued state reset via the file /s
[Re: [PATCH 0/3] clear_warn_once: add timed interval resetting] On 01/12/2020
(Tue 13:49) Petr Mladek wrote:
[...]
> Is this feature requested by RT people?
> Or is it just a possible use-case?
>
> I am not sure that RT is a really good example. The cron job is only
> part of the problem. The
[Re: [PATCH 0/3] clear_warn_once: add timed interval resetting] On 29/11/2020
(Sun 19:08) Andi Kleen wrote:
> On Thu, Nov 26, 2020 at 01:30:26AM -0500, Paul Gortmaker wrote:
> > But you currently can't make use of clear_warn_once unless you've got
> > debugfs enabled and moun
[Re: [PATCH 2/3] clear_warn_once: bind a timer to written reset value] On
30/11/2020 (Mon 11:20) Steven Rostedt wrote:
> On Thu, 26 Nov 2020 01:30:28 -0500
> Paul Gortmaker wrote:
>
> > +++ b/Documentation/admin-guide/clearing-warn-once.rst
> > @@ -7,3 +7,12 @@ echo
[Re: [PATCH 0/3] clear_warn_once: add timed interval resetting] On 27/11/2020
(Fri 17:13) Petr Mladek wrote:
> On Thu 2020-11-26 01:30:26, Paul Gortmaker wrote:
> > The existing clear_warn_once functionality is currently a manually
> > issued state reset via the file /s
-by: Paul Gortmaker
---
.../admin-guide/kernel-parameters.txt | 8 +++
kernel/panic.c| 21 +++
2 files changed, 29 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
een
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: John Ogness
Signed-off-by: Paul Gortmaker
---
.../admin-guide/clearing-warn-once.rst| 9 ++
kernel/panic.c| 32 +++
2 files changed, 41 insertions(+)
diff --git a/
ave tied in a variable that lets you now read the variable and see
the last value written.
Cc: Andi Kleen
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: John Ogness
Signed-off-by: Paul Gortmaker
---
kernel/panic.c | 25 -
1 file changed, 20 insertions(+)
are facing an issue and are
wondering "did this just happen once, or am I only being informed once?"
Tested with DEBUG_FS_ALLOW_ALL and DEBUG_FS_ALLOW_NONE on an otherwise
defconfig.
---
Cc: Andi Kleen
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: John Ogness
On 2020-11-09 8:07 p.m., Qian Cai wrote:
On Mon, 2020-11-09 at 13:04 +, Colin King wrote:
From: Colin Ian King
Currently the allocation of cpulist is based on the length of buf but does
not include the addition end of string '\0' terminator. Static analysis is
reporting this as a
t could just as easily be used to replace any placeholder token with
any other token or value only known at/after boot.
Signed-off-by: Paul Gortmaker
---
.../admin-guide/kernel-parameters.rst | 7 ++
lib/cpumask.c | 112 +-
2 files changed,
It is probably better that we don't have subsystem specific
abbreviations or aliases for generic CPU list specifications.
Hence we move the "all" from RCU out to lib/ so that it can be
used in any instance where CPU lists are being parsed.
Signed-off-by: Paul Gortmaker
---
Documenta
ing cpulist_parse() are runtime cases.
---
Cc: Frederic Weisbecker
Cc: "Paul E. McKenney"
Cc: Josh Triplett
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Li Zefan
Paul Gortmaker (4):
cpumask: un-inline cpulist_parse for SMP; prepare for ascii helpers
cpumask: make "all"
l in the SMP case, no functional
changes are anticipated with this move.
Signed-off-by: Paul Gortmaker
---
include/linux/cpumask.h | 8
lib/cpumask.c | 13 +
2 files changed, 21 insertions(+)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index f0d895d6ac39.
With global support for a CPU list alias of "all", it seems to just make
sense to also trivially extend support for an opposite "none" specifier.
Signed-off-by: Paul Gortmaker
---
Documentation/admin-guide/kernel-parameters.rst | 6 ++
lib/cpumask.c
On 2020-11-09 6:59 a.m., Zou Wei wrote:
Fix coccicheck warnings:
./lib/cpumask.c:342:6-13: WARNING: Comparison of 0/1 to bool variable
./lib/cpumask.c:351:33-40: WARNING: Comparison of 0/1 to bool variable
./lib/cpumask.c:406:3-11: WARNING: Assignment of 0/1 to bool variable
Reported-by:
On 2020-11-08 1:02 p.m., Paul E. McKenney wrote:
> Or I can carry them if you wish. My expected changes in response to
> this series are shown below, and are also what I used to test it.
Thanks Paul - that would get linux-next exposure w/o me pestering sfr.
If nobody else has objections,
t could just as easily be used to replace any placeholder token with
any other token or value only known at/after boot.
Signed-off-by: Paul Gortmaker
---
.../admin-guide/kernel-parameters.rst | 7 ++
lib/cpumask.c | 112 +-
2 files changed,
With global support for a CPU list alias of "all", it seems to just make
sense to also trivially extend support for an opposite "none" specifier.
Signed-off-by: Paul Gortmaker
---
Documentation/admin-guide/kernel-parameters.rst | 6 ++
lib/cpumask.c
d code more complex
operations not really appropriate for a header file, we prepare by
simply un-inlining it here and move it to the lib dir alongside the
other more complex cpumask functions.
Aside from an additional exported symbol, no functional changes are
anticipated with this move.
It is probably better that we don't have subsystem specific
abbreviations or aliases for generic CPU list specifications.
Hence we move the "all" from RCU out to lib/ so that it can be
used in any instance where CPU lists are being parsed.
Signed-off-by: Paul Gortmaker
---
Documenta
=16 in .config file.
Note that the two use cases (boot and runtime) are why you see "early"
parameter in the code - I entertained just sticking the string copy on
the stack vs. the early alloc dance, but this felt more correct/robust.
The cgroup and modular code using cpulist_pars
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: fbb9f8531a0d6693189783d295114db4c30624ca
Gitweb:
https://git.kernel.org/tip/fbb9f8531a0d6693189783d295114db4c30624ca
Author:Paul Gortmaker
AuthorDate:Thu, 02 Jul 2020 15:59:05 -07:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 46132e3ac58cb2ee48051ed80bffc0070ad59b2e
Gitweb:
https://git.kernel.org/tip/46132e3ac58cb2ee48051ed80bffc0070ad59b2e
Author:Paul Gortmaker
AuthorDate:Wed, 01 Jul 2020 14:34:18 -04:00
[Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917] On 20/07/2020 (Mon 16:21)
Peter Zijlstra wrote:
> On Mon, Jul 20, 2020 at 04:02:24PM +0200, Oleg Nesterov wrote:
> > I have to admit, I do not understand the usage of prev_state in schedule(),
> > it looks really, really subtle...
>
> Right, so
[Re: weird loadavg on idle machine post 5.7] On 02/07/2020 (Thu 17:15) Paul
Gortmaker wrote:
> [weird loadavg on idle machine post 5.7] On 02/07/2020 (Thu 13:15) Dave Jones
> wrote:
[...]
> > both implicated this commit:
> >
> > commit c6e7bd7afaeb3af55ffac12282803
[weird loadavg on idle machine post 5.7] On 02/07/2020 (Thu 13:15) Dave Jones
wrote:
> When I upgraded my firewall to 5.7-rc2 I noticed that on a mostly
> idle machine (that usually sees loadavg hover in the 0.xx range)
> that it was consistently above 1.00 even when there was nothing running.
>
e commit.
Fixes: ebc0f83c78a2 ("timers/nohz: Update NOHZ load in remote tick")
Cc: Scott Wood
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Signed-off-by: Paul Gortmaker
---
include/linux/sched/nohz.h | 5 +++--
kernel/sched/core.c| 2 +-
kernel/sched/loadavg
unused as the function calc_global_nohz() dropped using "ticks".
Fixes: c308b56b5398 ("sched: Fix nohz load accounting -- again!")
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Signed-off-by: Paul Gortmaker
---
include/linux/sched/loadavg.h | 2 +-
kernel/sched/loadavg.c| 2
z.h:18:35: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
Fixes: ebc0f83c78a2 ("timers/nohz: Update NOHZ load in remote tick")
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 4bd30106ddb26d2304adc5bb7bd269825300440d
Gitweb:
https://git.kernel.org/tip/4bd30106ddb26d2304adc5bb7bd269825300440d
Author:Paul Gortmaker
AuthorDate:Wed, 08 Apr 2020 19:52:16 -04:00
[Re: Fwd: linux-next: build failure after merge of the kbuild tree] On
06/05/2019 (Mon 21:07) Masahiro Yamada wrote:
> Hi Paul,
>
>
> On Mon, May 6, 2019 at 12:34 PM Paul Gortmaker
> wrote:
> >
> > [Fwd: linux-next: build failure after merge of the kbuild tree] On
[Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019
(Mon 11:19) Masahiro Yamada wrote:
> Hi Paul,
>
> In today's linux-next build testing,
> more "make ... explicitly non-modular"
> candidates showed up.
>
Hi Masahiro,
I am not 100% clear on what you are asking me.
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Signed-off-by: Paul Gortmaker
diff --git a/sound/soc/soc-acpi.c b/sound/soc/soc-acpi.c
index 4fb29f0e561e..444ce0602f76 100644
--- a/sound/soc/soc-acpi.c
+++ b/sound/soc/soc-acpi.c
@@ -4,6 +4,8 @@
//
// Copyright (c) 2013-15, Intel Corporation.
+#include
Kale
Cc: Pierre-Louis Bossart
Signed-off-by: Paul Gortmaker
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
index fd8d034cfec1..4a4a883f29f6 100644
--- a/drivers/soundwire/intel.c
+++ b/drivers/soundwire/intel.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
ts. For consistency, and
to avoid reboots in the same vein as the original commit, we make these
two instances of _once the same as the WARN*_ONCE instances are.
Cc: Andi Kleen
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Andrew Morton
Signed-off-by: Paul Gortmaker
---
Documen
[Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers] On
07/03/2019 (Thu 00:10) Pavel Machek wrote:
> On Wed 2019-01-16 13:24:31, Lee Jones wrote:
> > [...]
> >
> > > Paul Gortmaker (18):
> > > mfd: aat2870-core: Make it explicitly non-m
VICE_TABLE becomes
undefined here.
The easiest dependency solution is to simply defer the ACPI cleanup
until this change is present in mainline.
Cc: Lee Jones
Signed-off-by: Paul Gortmaker
diff --git a/drivers/mfd/tps68470.c b/drivers/mfd/tps68470.c
index a5981a79b29a..4a4df4ffd18c 100644
--- a/d
1 - 100 of 4512 matches
Mail list logo
