Make SRCU be once again optional
Subsystems (35)
RFC PATCH 1/1 Make SRCU be once again optional
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
My current plan is to push this into v4.13.
Thanx, Paul
------------------------------------------------------------------------
commit e01ef0529ed548c1b30206058c2b5eecbbc07998
Author: Paul E. McKenney <[email protected]> Date: Fri Apr 28 13:53:04 2017 -0700
srcu: Make SRCU be once again optional
Commit d160a727c40e ("srcu: Make SRCU be built by default") in response to build errors, which were caused by code that included srcu.h despite !SRCU. However, srcutiny.o is almost 2K of code, which is not insignificant for those attempting to run the Linux kernel on IoT devices. This commit therefore makes SRCU be once again optional, and adjusts srcu.h to allow error-free inclusion in !SRCU kernel builds.
include/linux/srcu.h +1 -1
@@ -62,7 +62,7 @@ int init_srcu_struct(struct srcu_struct *sp);#include <linux/srcutree.h> #elif defined(CONFIG_CLASSIC_SRCU )#include <linux/srcuclassic.h> -#else +#elif defined(CONFIG_SRCU )#error "Unknown SRCU implementation specified to kernel configuration"#endif
init/Kconfig +0 -1
@@ -521,7 +521,6 @@ config RCU_EXPERT config SRCU bool - default y help This option selects the sleepable version of RCU. This version permits arbitrary sleeping or blocking within RCU read-side critical
Quoted 8 lines · Paul E. McKenney
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
My current plan is to push this into v4.13.
Excellent!
If every maintainer finds a way to (optionally) reduce the size of the code they maintain by 2K then we'll get a much smaller kernel pretty soon.
Quoted 18 lines
Thanx, Paul
------------------------------------------------------------------------
commit
e01ef0529ed548c1b30206058c2b5eecbbc07998Author: Paul E. McKenney <[email protected]> Date: Fri Apr 28 13:53:04 2017 -0700srcu: Make SRCU be once again optional
Commit
d160a727c40e("srcu: Make SRCU be built by default") in response to build errors, which were caused by code that includedsrcu.hdespite !SRCU. However, srcutiny.o is almost 2K of code, which is not insignificant for those attempting to run the Linux kernel on IoT devices. This commit therefore makes SRCU be once again optional, and adjustssrcu.hto allow error-free inclusion in !SRCU kernel builds.
Quoted 2 lines
Signed-off-by Paul E. McKenney <[email protected]>Cc Nicolas Pitre <[email protected]>
Quoted 28 lines
include/linux/srcu.h +1
-1@@ -62,7 +62,7 @@ int init_srcu_struct(struct srcu_struct *sp);#include <linux/srcutree.h> #elif defined(CONFIG_CLASSIC_SRCU )#include <linux/srcuclassic.h> -#else +#elif defined(CONFIG_SRCU )#error "Unknown SRCU implementation specified to kernel configuration"#endif init/Kconfig +0
-1@@ -521,7 +521,6 @@ config RCU_EXPERT config SRCU bool - default y help This option selects the sleepable version of RCU. This version permits arbitrary sleeping or blocking within RCU read-side critical
Paul E. McKenney
AppliedQuoted 9 lines · Nicolas Pitre
Quoted 7 lines · Paul E. McKenney
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
Quoted 7 lines
Quoted 1 line
My current plan is to push this into v4.13.
Excellent!
If every maintainer finds a way to (optionally) reduce the size of the code they maintain by 2K then we'll get a much smaller kernel pretty soon.
I would feel better if it wasn't me who had added the 2K, but then again, I do look forward to seeing a negative-sized kernel! ;-)
Quoted 15 lines
Quoted 15 lines
------------------------------------------------------------------------
commit
e01ef0529ed548c1b30206058c2b5eecbbc07998Author: Paul E. McKenney <[email protected]> Date: Fri Apr 28 13:53:04 2017 -0700srcu: Make SRCU be once again optional
Commit
d160a727c40e("srcu: Make SRCU be built by default") in response to build errors, which were caused by code that includedsrcu.hdespite !SRCU. However, srcutiny.o is almost 2K of code, which is not insignificant for those attempting to run the Linux kernel on IoT devices. This commit therefore makes SRCU be once again optional, and adjustssrcu.hto allow error-free inclusion in !SRCU kernel builds.
Quoted 4 lines
Quoted 2 lines
Signed-off-by Paul E. McKenney <[email protected]>Cc Nicolas Pitre <[email protected]>Acked-by Nicolas Pitre <[email protected]>
Applied, thank you!
Thanx, Paul
Quoted 28 lines
Quoted 27 lines
include/linux/srcu.h +1
-1@@ -62,7 +62,7 @@ int init_srcu_struct(struct srcu_struct *sp);#include <linux/srcutree.h> #elif defined(CONFIG_CLASSIC_SRCU )#include <linux/srcuclassic.h> -#else +#elif defined(CONFIG_SRCU )#error "Unknown SRCU implementation specified to kernel configuration"#endif init/Kconfig +0
-1@@ -521,7 +521,6 @@ config RCU_EXPERT config SRCU bool - default y help This option selects the sleepable version of RCU. This version permits arbitrary sleeping or blocking within RCU read-side critical
Quoted 12 lines · Paul E. McKenney
Quoted 11 lines · Nicolas Pitre
Quoted 8 lines · Paul E. McKenney
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
My current plan is to push this into v4.13.
Quoted 8 lines
Quoted 5 lines
Excellent!
If every maintainer finds a way to (optionally) reduce the size of the code they maintain by 2K then we'll get a much smaller kernel pretty soon.
I would feel better if it wasn't me who had added the 2K, but then again, I do look forward to seeing a negative-sized kernel! ;-)
And I am getting a lot of offlist pressure to remove both Tiny RCU and Tiny SRCU. I am pushing back, but I might or might not prevail. In case my pushback gets pushed back, do you have a -tiny tree or some such where the code could go?
Thanx, Paul
Quoted 52 lines
Quoted 15 lines
Quoted 15 lines
------------------------------------------------------------------------
commit
e01ef0529ed548c1b30206058c2b5eecbbc07998Author: Paul E. McKenney <[email protected]> Date: Fri Apr 28 13:53:04 2017 -0700srcu: Make SRCU be once again optional
Commit
d160a727c40e("srcu: Make SRCU be built by default") in response to build errors, which were caused by code that includedsrcu.hdespite !SRCU. However, srcutiny.o is almost 2K of code, which is not insignificant for those attempting to run the Linux kernel on IoT devices. This commit therefore makes SRCU be once again optional, and adjustssrcu.hto allow error-free inclusion in !SRCU kernel builds.Quoted 4 lines
Quoted 2 lines
Signed-off-by Paul E. McKenney <[email protected]>Cc Nicolas Pitre <[email protected]>Acked-by Nicolas Pitre <[email protected]>Applied, thank you!
Thanx, Paul
Quoted 28 lines
Quoted 27 lines
include/linux/srcu.h +1
-1@@ -62,7 +62,7 @@ int init_srcu_struct(struct srcu_struct *sp);#include <linux/srcutree.h> #elif defined(CONFIG_CLASSIC_SRCU )#include <linux/srcuclassic.h> -#else +#elif defined(CONFIG_SRCU )#error "Unknown SRCU implementation specified to kernel configuration"#endif init/Kconfig +0
-1@@ -521,7 +521,6 @@ config RCU_EXPERT config SRCU bool - default y help This option selects the sleepable version of RCU. This version permits arbitrary sleeping or blocking within RCU read-side critical
Quoted 19 lines · Paul E. McKenney
Quoted 18 lines · Paul E. McKenney
Quoted 16 lines · Nicolas Pitre
Quoted 8 lines · Paul E. McKenney
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
My current plan is to push this into v4.13.
Excellent!
If every maintainer finds a way to (optionally) reduce the size of the code they maintain by 2K then we'll get a much smaller kernel pretty soon.
Quoted 7 lines
Quoted 2 lines
I would feel better if it wasn't me who had added the 2K, but then again, I do look forward to seeing a negative-sized kernel! ;-)
And I am getting a lot of offlist pressure to remove both Tiny RCU and Tiny SRCU. I am pushing back, but I might or might not prevail. In case my pushback gets pushed back, do you have a -tiny tree or some such where the code could go?
And adding Josh Triplett on CC, who I should have CCed to start with.
Thanx, Paul
Quoted 19 lines · Paul E. McKenney
Quoted 18 lines · Paul E. McKenney
Quoted 16 lines · Nicolas Pitre
Quoted 8 lines · Paul E. McKenney
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
My current plan is to push this into v4.13.
Excellent!
If every maintainer finds a way to (optionally) reduce the size of the code they maintain by 2K then we'll get a much smaller kernel pretty soon.
Quoted 7 lines
Quoted 2 lines
I would feel better if it wasn't me who had added the 2K, but then again, I do look forward to seeing a negative-sized kernel! ;-)
And I am getting a lot of offlist pressure to remove both Tiny RCU and Tiny SRCU. I am pushing back, but I might or might not prevail. In case my pushback gets pushed back, do you have a -tiny tree or some such where the code could go?
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
Nicolas
Quoted 29 lines · Nicolas Pitre
Quoted 19 lines · Paul E. McKenney
Quoted 18 lines · Paul E. McKenney
Quoted 16 lines · Nicolas Pitre
Quoted 8 lines · Paul E. McKenney
Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way. It should be worth about 2K compared to current -next, which gave up the 2K compared to v4.10. So really getting things back to where they were.
My current plan is to push this into v4.13.
Excellent!
If every maintainer finds a way to (optionally) reduce the size of the code they maintain by 2K then we'll get a much smaller kernel pretty soon.
Quoted 7 lines
Quoted 2 lines
I would feel better if it wasn't me who had added the 2K, but then again, I do look forward to seeing a negative-sized kernel! ;-)
And I am getting a lot of offlist pressure to remove both Tiny RCU and Tiny SRCU. I am pushing back, but I might or might not prevail. In case my pushback gets pushed back, do you have a -tiny tree or some such where the code could go?
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
Thanx, Paul
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 12 May 2017, Paul E. McKenney wrote:
[ . . . ]
Quoted 7 lines
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
And still quite a bit of back and forth. How are things with tty?
One question that came up -- what sort of SoCs are you targeting? A number of people are insisting that smartphone SoCs with 256M DRAM are the minimal systems of the future. This seems unlikely to me, given the potential for extremely cheap SoCs with EDRAM or some such, but figured I should ask what you are targeting.
Thanx, Paul
Quoted 14 lines · Paul E. McKenney
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 12 May 2017, Paul E. McKenney wrote:
[ . . . ]
Quoted 7 lines
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
Quoted 7 lines
And still quite a bit of back and forth. How are things with tty?
One question that came up -- what sort of SoCs are you targeting? A number of people are insisting that smartphone SoCs with 256M DRAM are the minimal systems of the future. This seems unlikely to me, given the potential for extremely cheap SoCs with EDRAM or some such, but figured I should ask what you are targeting.
I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for smart phones but really cheap IoT devices. That's the next area for (trimmed down) Linux to conquer. Example targets are STM32 chips.
Please see the following for the rationale and how to get there:
https://lwn.net/Articles/721074/
http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
Nicolas
Quoted 28 lines · Nicolas Pitre
Quoted 14 lines · Paul E. McKenney
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 12 May 2017, Paul E. McKenney wrote:
[ . . . ]
Quoted 7 lines
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
Quoted 7 lines
And still quite a bit of back and forth. How are things with tty?
One question that came up -- what sort of SoCs are you targeting? A number of people are insisting that smartphone SoCs with 256M DRAM are the minimal systems of the future. This seems unlikely to me, given the potential for extremely cheap SoCs with EDRAM or some such, but figured I should ask what you are targeting.
I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for smart phones but really cheap IoT devices. That's the next area for (trimmed down) Linux to conquer. Example targets are STM32 chips.
Quoted 5 lines
Please see the following for the rationale and how to get there:
https://lwn.net/Articles/721074/
http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
Ah, thank you for the reminder. I did read that article, but somehow got a few megabytes stuck in my head instead of the correct quarter meg.
Anyway, don't look now, but Tiny {S,}RCU just might live on, for a bit longer, anyway.
Thanx, Paul
Arnd Bergmann
maintainerQuoted 33 lines · Paul E. McKenney
Quoted 32 lines · Nicolas Pitre
Quoted 14 lines · Paul E. McKenney
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 12 May 2017, Paul E. McKenney wrote:
[ . . . ]
Quoted 7 lines
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
Quoted 7 lines
And still quite a bit of back and forth. How are things with tty?
One question that came up -- what sort of SoCs are you targeting? A number of people are insisting that smartphone SoCs with 256M DRAM are the minimal systems of the future. This seems unlikely to me, given the potential for extremely cheap SoCs with EDRAM or some such, but figured I should ask what you are targeting.
I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for smart phones but really cheap IoT devices. That's the next area for (trimmed down) Linux to conquer. Example targets are STM32 chips.
Please see the following for the rationale and how to get there:
Quoted 7 lines
Quoted 1 line
http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
Ah, thank you for the reminder. I did read that article, but somehow got a few megabytes stuck in my head instead of the correct quarter meg.
Anyway, don't look now, but Tiny {S,}RCU just might live on, for a bit longer, anyway.
It took me around 200000 randconfig builds since May, but I eventually ran into the regression caused by this patch, building an ARM kernel with the defconfig from https://pastebin.com/TiTWHP8t as input results in this build failure:
CC arch/arm/kernel/asm-offsets.s
In file included from ./include/linux/notifier.h:16:0,
from ./include/linux/memory_hotplug.h:7,
from ./include/linux/mmzone.h:775,
from ./include/linux/gfp.h:6,
from ./include/linux/mm.h:10,
from arch/arm/kernel/asm-offsets.c:15:
./include/linux/srcu.h: In function 'srcu_read_lock_held':
./include/linux/srcu.h:99:25: error: 'struct srcu_struct' has no
member named 'dep_map'
return lock_is_held(&sp->dep_map);
^~
./include/linux/srcu.h: In function 'srcu_read_lock':
./include/linux/srcu.h:160:24: error: 'struct srcu_struct' has no
member named 'dep_map'
rcu_lock_acquire(&(sp)->dep_map);
^~
./include/linux/srcu.h: In function 'srcu_read_unlock':
./include/linux/srcu.h:174:24: error: 'struct srcu_struct' has no
member named 'dep_map'
rcu_lock_release(&(sp)->dep_map);
^~I think what happened here is that randconfig builds basically never hit the CONFIG_SRCU=n case since lots of other things 'select SRCU', directly or indirectly. Until commit c9afbec27089 ("debugfs: purge obsolete SRCU based removal protection"), SRCU was selected by debugfs, which is practically always on, now it has become much easier to disable it, but it's still fairly unlikely.
Arnd
Arnd Bergmann
maintainerQuoted 9 lines · Arnd Bergmann
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 2 Jun 2017, Paul E. McKenney wrote:
It took me around 200000 randconfig builds since May, but I eventually ran into the regression caused by this patch, building an ARM kernel with the defconfig from https://pastebin.com/TiTWHP8t as input results in this build failure:
Sorry, wrong file, try this one instead:
Arnd
Quoted 40 lines · Arnd Bergmann
Quoted 38 lines · Paul E. McKenney
Quoted 28 lines · Nicolas Pitre
Quoted 14 lines · Paul E. McKenney
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 12 May 2017, Paul E. McKenney wrote:
[ . . . ]
Quoted 7 lines
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
Quoted 7 lines
And still quite a bit of back and forth. How are things with tty?
One question that came up -- what sort of SoCs are you targeting? A number of people are insisting that smartphone SoCs with 256M DRAM are the minimal systems of the future. This seems unlikely to me, given the potential for extremely cheap SoCs with EDRAM or some such, but figured I should ask what you are targeting.
I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for smart phones but really cheap IoT devices. That's the next area for (trimmed down) Linux to conquer. Example targets are STM32 chips.
Quoted 5 lines
Please see the following for the rationale and how to get there:
https://lwn.net/Articles/721074/
http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
Ah, thank you for the reminder. I did read that article, but somehow got a few megabytes stuck in my head instead of the correct quarter meg.
Quoted 7 lines
Quoted 2 lines
Anyway, don't look now, but Tiny {S,}RCU just might live on, for a bit longer, anyway.
It took me around 200000 randconfig builds since May, but I eventually ran into the regression caused by this patch, building an ARM kernel with the defconfig from https://pastebin.com/TiTWHP8t as input results in this build failure:
Yow!!! I am impressed!
Quoted 12 lines
CC
arch/arm/kernel/asm-offsets.s
In file included from./include/linux/notifier.h:16:0,from ./include/linux/memory_hotplug.h:7, from ./include/linux/mmzone.h:775, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from arch/arm/kernel/asm-offsets.c:15: ./include/linux/srcu.h: In function 'srcu_read_lock_held': ./include/linux/srcu.h:99:25: error: 'struct srcu_struct' has no member named 'dep_map' return lock_is_held(&sp->dep_map); ^~
This one I get -- I messed up and let the compiler evaluate ->dep_map even for !CONFIG_DEBUG_LOCK_ALLOC. Does the patch below help?
Quoted 10 lines
./include/linux/srcu.h: In function 'srcu_read_lock':./include/linux/srcu.h:160:24: error: 'structsrcu_struct' has no member named 'dep_map'rcu_lock_acquire(&(sp)->dep_map); ^~ ./include/linux/srcu.h: In function 'srcu_read_unlock': ./include/linux/srcu.h:174:24: error: 'struct srcu_struct' has no member named 'dep_map' rcu_lock_release(&(sp)->dep_map); ^~
These two I don't get given the definitions for !CONFIG_DEBUG_LOCK_ALLOC:
# define rcu_lock_acquire(a) do { } while (0)
# define rcu_lock_release(a) do { } while (0)Is your build somehow picking up a different definition? Or are you using an older kernel (if so, please let me know the version.)
Quoted 6 lines
I think what happened here is that randconfig builds basically never hit the
CONFIG_SRCU=ncase since lots of other things 'select SRCU', directly or indirectly. Until commitc9afbec27089("debugfs: purge obsolete SRCU based removal protection"), SRCU was selected by debugfs, which is practically always on, now it has become much easier to disable it, but it's still fairly unlikely.
It has been getting harder.
Another option would be simply conditionally compile out all or most of include/linux/srcu.h for !CONFIG_SRCU builds.
Thoughts?
Thanx, Paul
------------------------------------------------------------------------
include/linux/srcu.h +4 -2
@@ -94,9 +94,11 @@ void synchronize_srcu(struct srcu_struct *sp);*/ static inline int srcu_read_lock_held (struct srcu_struct *sp) { -if (!debug_lockdep_rcu_enabled ()) -return 1 ; +#ifdef CONFIG_PROVE_RCU return lock_is_held (&sp->dep_map); +#else /* #ifdef CONFIG_PROVE_RCU */ +return 1 ; +#endif /* #else #ifdef CONFIG_PROVE_RCU */ }#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
Arnd Bergmann
maintainerQuoted 78 lines · Paul E. McKenney
Quoted 40 lines · Arnd Bergmann
Quoted 38 lines · Paul E. McKenney
Quoted 28 lines · Nicolas Pitre
Quoted 14 lines · Paul E. McKenney
Quoted 2 lines · Paul E. McKenney
Quoted 1 line · Nicolas Pitre
On Fri, 12 May 2017, Paul E. McKenney wrote:
[ . . . ]
Quoted 7 lines
Quoted 5 lines
No. "Available in mainline" is the name of the game for all I do. If it can't be made acceptable for mainline then it basically has no chance of gaining traction and becoming generally useful. My approach is therefore to always find solutions that can be maintained upstream and contributed to with minimal fuss by anyone.
OK, then wish me luck. ;-)
Quoted 7 lines
And still quite a bit of back and forth. How are things with tty?
One question that came up -- what sort of SoCs are you targeting? A number of people are insisting that smartphone SoCs with 256M DRAM are the minimal systems of the future. This seems unlikely to me, given the potential for extremely cheap SoCs with EDRAM or some such, but figured I should ask what you are targeting.
I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for smart phones but really cheap IoT devices. That's the next area for (trimmed down) Linux to conquer. Example targets are STM32 chips.
Quoted 5 lines
Please see the following for the rationale and how to get there:
https://lwn.net/Articles/721074/
http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
Ah, thank you for the reminder. I did read that article, but somehow got a few megabytes stuck in my head instead of the correct quarter meg.
Quoted 7 lines
Quoted 2 lines
Anyway, don't look now, but Tiny {S,}RCU just might live on, for a bit longer, anyway.
It took me around 200000 randconfig builds since May, but I eventually ran into the regression caused by this patch, building an ARM kernel with the defconfig from https://pastebin.com/TiTWHP8t as input results in this build failure:
Yow!!! I am impressed!
Quoted 12 lines
CC
arch/arm/kernel/asm-offsets.s
In file included from./include/linux/notifier.h:16:0,from ./include/linux/memory_hotplug.h:7, from ./include/linux/mmzone.h:775, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from arch/arm/kernel/asm-offsets.c:15: ./include/linux/srcu.h: In function 'srcu_read_lock_held': ./include/linux/srcu.h:99:25: error: 'struct srcu_struct' has no member named 'dep_map' return lock_is_held(&sp->dep_map); ^~This one I get -- I messed up and let the compiler evaluate ->dep_map even for !CONFIG_DEBUG_LOCK_ALLOC. Does the patch below help?
Quoted 10 lines
./include/linux/srcu.h: In function 'srcu_read_lock':./include/linux/srcu.h:160:24: error: 'structsrcu_struct' has no member named 'dep_map'rcu_lock_acquire(&(sp)->dep_map); ^~ ./include/linux/srcu.h: In function 'srcu_read_unlock': ./include/linux/srcu.h:174:24: error: 'struct srcu_struct' has no member named 'dep_map' rcu_lock_release(&(sp)->dep_map); ^~
Quoted 7 lines
These two I don't get given the definitions for !CONFIG_DEBUG_LOCK_ALLOC:
# define rcu_lock_acquire(a) do { } while (0) # define rcu_lock_release(a) do { } while (0)Is your build somehow picking up a different definition? Or are you using an older kernel (if so, please let me know the version.)
This is using today's linux-next, but I got the same thing pretty much for every step of the bisection since May.
My configuration has
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_RCU_NEED_SEGCBLIST is not set
# CONFIG_PHY_LANTIQ_RCU_USB2 is not set
# CONFIG_PROVE_RCU is not set
# CONFIG_RCU_PERF_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_PROVE_RCU is not setCONFIG_DEBUG_LOCK_ALLOC=y
Quoted 8 lines
include/linux/srcu.h +0
-0@@ -94,9 +94,11 @@ void synchronize_srcu(struct srcu_struct *sp);*/ static inline int srcu_read_lock_held (struct srcu_struct *sp) {
include/linux/srcu.h void synchronize_srcu(struct srcu_struct *sp); · line 104
Quoted 10 lines
include/linux/srcu.h +4
-2-if (!debug_lockdep_rcu_enabled ()) -return 1 ; +#ifdef CONFIG_PROVE_RCU return lock_is_held (&sp->dep_map); +#else /* #ifdef CONFIG_PROVE_RCU */ +return 1 ; +#endif /* #else #ifdef CONFIG_PROVE_RCU */ }#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
That fixed the first warning for me, doing the same thing for all three fixed the rest:
include/linux/srcu.h +4 -2
@@ -94,9 +94,11 @@ void synchronize_srcu(struct srcu_struct *sp);*/ static inline int srcu_read_lock_held (struct srcu_struct *sp) { -if (!debug_lockdep_rcu_enabled ()) -return 1 ; +#ifdef CONFIG_PROVE_RCU return lock_is_held (&sp->dep_map); +#else /* #ifdef CONFIG_PROVE_RCU */ +return 1 ; +#endif /* #else #ifdef CONFIG_PROVE_RCU */ }#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
@@ -157,7 +159,9 @@ static inline int srcu_read_lock(struct
srcu_struct *sp) __acquires(sp)
int retval;
retval = __srcu_read_lock(sp);
+#ifdef CONFIG_PROVE_RCU
rcu_lock_acquire(&(sp)->dep_map);
+#endif
return retval;}
@@ -171,7 +175,9 @@ static inline int srcu_read_lock(struct srcu_struct *sp) __acquires(sp)
static inline void srcu_read_unlock(struct srcu_struct *sp, int idx)
__releases(sp)
{
+#ifdef CONFIG_PROVE_RCU
rcu_lock_release(&(sp)->dep_map);
+#endif
__srcu_read_unlock(sp, idx);}
Arnd Bergmann
maintainerQuoted 3 lines · Arnd Bergmann
That fixed the first warning for me, doing the same thing for all three fixed the rest
Now with my workaround applied and the original randconfig that triggered the failure, I get another problem:
drivers/base/power/wakeup.c:68:1: error: data definition has no type or storage class [-Werror]
DEFINE_STATIC_SRCU(wakeup_srcu);
Evidently there is at least one driver that uses SRCU but doesn't 'select SRCU' in Kconfig. There are probably others that just haven't been found.
Arnd
Quoted 9 lines · Arnd Bergmann
Quoted 3 lines · Arnd Bergmann
That fixed the first warning for me, doing the same thing for all three fixed the rest
Now with my workaround applied and the original randconfig that triggered the failure, I get another problem:
Quoted 6 lines
drivers/base/power/wakeup.c:68:1: error: data definition has no type or storage class [-Werror]
DEFINE_STATIC_SRCU(wakeup_srcu);Evidently there is at least one driver that uses SRCU but doesn't 'select SRCU' in
Kconfig. There are probably others that just haven't been found.
Does adding "select SRCU" on "config PM_SLEEP" in kernel/power/Kconfig fix this?
Thanx, Paul
Arnd Bergmann
maintainerQuoted 14 lines · Paul E. McKenney
Quoted 13 lines · Arnd Bergmann
Quoted 3 lines · Arnd Bergmann
That fixed the first warning for me, doing the same thing for all three fixed the rest
Now with my workaround applied and the original randconfig that triggered the failure, I get another problem:
drivers/base/power/wakeup.c:68:1: error: data definition has no type or storage class [-Werror]
DEFINE_STATIC_SRCU(wakeup_srcu);
Quoted 5 lines
Quoted 2 lines
Evidently there is at least one driver that uses SRCU but doesn't 'select SRCU' in
Kconfig. There are probably others that just haven't been found.Does adding "select SRCU" on "config
PM_SLEEP" inkernel/power/Kconfigfix this?
I'm sure it does, but the point I was making is that we probably have a number of those, and would never find the other ones through the current build test setup.
I've now tried disabling a ridiculous number of options to come up with a setup that never enables SRCU. Interestingly, that also means we don't get the drivers/base/power/wakeup.c problem in 'allmodconfig', though I did get a link-time error:
kernel/locking/lockdep.o: In function `lockdep_rcu_suspicious':
lockdep.c:(.text+0x2704): undefined reference to rcu_scheduler_active' kernel/rcu/update.o: In function debug_lockdep_rcu_enabled':
update.c:(.text+0x40): undefined reference to rcu_scheduler_active' kernel/rcu/update.o: In function rcu_read_lock_bh_held':
update.c:(.text+0xa8): undefined reference to rcu_scheduler_active' kernel/rcu/update.o: In function rcu_read_lock_sched_held':
update.c:(.text+0xce0): undefined reference to rcu_scheduler_active' kernel/rcu/update.o: In function rcu_read_lock_held':
update.c:(.text+0xd40): undefined reference to rcu_scheduler_active' kernel/rcu/update.o:update.c:(.text+0x10ac): more undefined references to rcu_scheduler_active' followmm/kmemleak.o: In function `kmemleak_scan':
kmemleak.c:(.text+0x1768): undefined reference to __end_ro_after_init' kmemleak.c:(.text+0x176c): undefined reference to __start_ro_after_init' Makefile:1029: recipe for target 'vmlinux' failed
Turning off lockdep and kmemleak gives me a working allmodconfig build. I'm doing some more testing on ARM, but it looks like this is a dark corner of the randconfig state space that I'm not sure I want to explore more.
Doing an hour of randconfig builds, I already found exactly two missing 'select SRCU':
ERROR: "__srcu_read_unlock" [drivers/infiniband/core/ib_uverbs.ko] undefined! drivers/base/power/wakeup.c:68:1: error: type defaults to 'int' in declaration of 'DEFINE_STATIC_SRCU' [-Werror=implicit-int]
See below for my test patch. Without COMMON_CLK, PM_SLEEP and BLOCK, the number useful configurations is very limited.
Arnd
arch/Kconfig +1 -0
@@ -91,6 +91,7 @@ config STATIC_KEYS_SELFTEST config OPTPROBES def_bool y depends on KPROBES && HAVE_OPTPROBES + depends on BROKEN || !PREEMPT select TASKS_RCU if PREEMPT config KPROBES_ON_FTRACE
arch/arm/Kconfig +7 -2
@@ -330,7 +330,7 @@ choice config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU + depends on MMU && BROKEN select ARM_HAS_SG_CHAIN select ARM_PATCH_PHYS_VIRT select AUTO_ZRELADDR
@@ -345,7 +345,7 @@ config ARCH_MULTIPLATFORM config ARM_SINGLE_ARMV7M bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" - depends on !MMU + depends on !MMU && BROKEN select ARM_NVIC select AUTO_ZRELADDR select TIMER_OF
@@ -463,6 +463,7 @@ config ARCH_IXP4XX config ARCH_DOVE bool "Marvell Dove" + depends on BROKEN select CPU_PJ4 select GENERIC_CLOCKEVENTS select GPIOLIB
@@ -506,6 +507,7 @@ config ARCH_W90X900 config ARCH_LPC32XX bool "NXP LPC32XX" + depends on BROKEN select ARM_AMBA select CLKDEV_LOOKUP select CLKSRC_LPC32XX
@@ -522,6 +524,7 @@ config ARCH_LPC32XX config ARCH_PXA bool "PXA2xx/PXA3xx-based" depends on MMU + depends on BROKEN select ARCH_MTD_XIP select ARM_CPU_SUSPEND if PM select AUTO_ZRELADDR
@@ -563,6 +566,7 @@ config ARCH_RPC config ARCH_SA1100 bool "SA1100-based" + depends on BROKEN select ARCH_MTD_XIP select ARCH_SPARSEMEM_ENABLE select CLKDEV_LOOKUP
@@ -584,6 +588,7 @@ config ARCH_SA1100 config ARCH_S3C24XX bool "Samsung S3C24XX SoCs" + depends on BROKEN select ATAGS select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM
arch/arm/kvm/Kconfig +1 -1
@@ -20,7 +20,7 @@ if VIRTUALIZATION config KVM bool "Kernel-based Virtual Machine (KVM) support" - depends on MMU && OF + depends on MMU && OF && BROKEN select PREEMPT_NOTIFIERS select ANON_INODES select ARM_GIC
block/Kconfig +1 -0
@@ -4,6 +4,7 @@ # menuconfig BLOCK bool "Enable the block layer" if EXPERT + depends on BROKEN default y select SBITMAP select SRCU
drivers/clk/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HAVE_CLK_PREPARE config COMMON_CLK bool + depends on BROKEN select HAVE_CLK_PREPARE select CLKDEV_LOOKUP select SRCU
drivers/cpufreq/Kconfig +1 -0
@@ -2,6 +2,7 @@ menu "CPU Frequency scaling" config CPU_FREQ bool "CPU Frequency scaling" + depends on BROKEN select SRCU help CPU Frequency scaling allows you to change the clock speed of
drivers/dax/Kconfig +1 -0
@@ -1,5 +1,6 @@ menuconfig DAX tristate "DAX: direct access to differentiated memory" + depends on BROKEN select SRCU default m if NVDIMM_DAX
drivers/devfreq/Kconfig +1 -0
@@ -1,5 +1,6 @@ menuconfig PM_DEVFREQ bool "Generic Dynamic Voltage and Frequency Scaling (DVFS) support" + depends on BROKEN select SRCU select PM_OPP help
(quoted diff) +0 -0
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index e8af1f5e8a79..20d3bcd5a638 100644
drivers/gpu/drm/amd/amdgpu/Kconfig +1 -1
@@ -25,7 +25,7 @@ config DRM_AMDGPU_CIK config DRM_AMDGPU_USERPTR bool "Always enable userptr write support" - depends on DRM_AMDGPU + depends on DRM_AMDGPU && BROKEN select MMU_NOTIFIER help This option selects CONFIG_MMU_NOTIFIER if it isn't already
drivers/gpu/drm/i915/Kconfig +1 -1
@@ -84,7 +84,7 @@ config DRM_I915_COMPRESS_ERROR config DRM_I915_USERPTR bool "Always enable userptr support" - depends on DRM_I915 + depends on DRM_I915 && BROKEN select MMU_NOTIFIER default y help
drivers/gpu/drm/radeon/Kconfig +1 -1
@@ -1,6 +1,6 @@ config DRM_RADEON_USERPTR bool "Always enable userptr support" - depends on DRM_RADEON + depends on DRM_RADEON && BROKEN select MMU_NOTIFIER help This option selects CONFIG_MMU_NOTIFIER if it isn't already
(quoted diff) +0 -0
b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c164e1..ea6da47c136a 100644
drivers/hwtracing/coresight/Kconfig +1 -0
@@ -3,6 +3,7 @@ # menuconfig CORESIGHT bool "CoreSight Tracing Support" + depends on BROKEN select ARM_AMBA select PERF_EVENTS help
drivers/hwtracing/stm/Kconfig +1 -0
@@ -1,5 +1,6 @@ config STM tristate "System Trace Module devices" + depends on BROKEN select CONFIGFS_FS select SRCU help
drivers/infiniband/Kconfig +1 -1
@@ -51,7 +51,7 @@ config INFINIBAND_USER_MEM config INFINIBAND_ON_DEMAND_PAGING bool "InfiniBand on-demand paging support" - depends on INFINIBAND_USER_MEM + depends on INFINIBAND_USER_MEM && BROKEN select MMU_NOTIFIER default y ---help---
(quoted diff) +0 -0
b/drivers/infiniband/hw/hfi1/Kconfig
index 7b146b67a80f..b41fd3506be9 100644
drivers/infiniband/hw/hfi1/Kconfig +1 -1
@@ -1,6 +1,6 @@ config INFINIBAND_HFI1 tristate "Intel OPA Gen1 support" - depends on X86_64 && INFINIBAND_RDMAVT && I2C + depends on X86_64 && INFINIBAND_RDMAVT && I2C && BROKEN select MMU_NOTIFIER select CRC32 select I2C_ALGOBIT
drivers/iommu/Kconfig +2 -2
@@ -128,7 +128,7 @@ config AMD_IOMMU config AMD_IOMMU_V2 tristate "AMD IOMMU Version 2 driver" - depends on AMD_IOMMU + depends on AMD_IOMMU && BROKEN select MMU_NOTIFIER ---help--- This option enables support for the AMD IOMMUv2 features of the IOMMU
@@ -154,7 +154,7 @@ config INTEL_IOMMU config INTEL_IOMMU_SVM bool "Support for Shared Virtual Memory with Intel IOMMU" - depends on INTEL_IOMMU && X86 + depends on INTEL_IOMMU && X86 && BROKEN select PCI_PASID select MMU_NOTIFIER help
drivers/md/Kconfig +1 -1
@@ -4,7 +4,7 @@ menuconfig MD bool "Multiple devices driver support (RAID and LVM)" - depends on BLOCK + depends on BLOCK && BROKEN select SRCU help Support multiple physical spindles through a single logical device.
drivers/misc/Kconfig +1 -1
@@ -284,7 +284,7 @@ config QCOM_COINCELL config SGI_GRU tristate "SGI GRU driver" - depends on X86_UV && SMP + depends on X86_UV && SMP && BROKEN default n select MMU_NOTIFIER ---help---
drivers/net/Kconfig +2 -0
@@ -238,6 +238,7 @@ config MACSEC config NETCONSOLE tristate "Network console logging support" + depends on BROKEN ---help--- If you want to log kernel messages over the network, enable this. See <file:Documentation/networking/netconsole.txt> for details.
@@ -254,6 +255,7 @@ config NETCONSOLE_DYNAMIC config NETPOLL def_bool NETCONSOLE + depends on BROKEN select SRCU config NET_POLL_CONTROLLER
drivers/opp/Kconfig +1 -0
@@ -1,5 +1,6 @@ config PM_OPP bool + depends on BROKEN select SRCU ---help--- SOCs have a standard set of tuples consisting of frequency and
drivers/xen/Kconfig +1 -1
@@ -146,7 +146,7 @@ config XEN_XENBUS_FRONTEND config XEN_GNTDEV tristate "userspace grant access device driver" - depends on XEN + depends on XEN && BROKEN default m select MMU_NOTIFIER help
fs/btrfs/Kconfig +1 -0
@@ -1,5 +1,6 @@ config BTRFS_FS tristate "Btrfs filesystem support" + depends on BROKEN select CRYPTO select CRYPTO_CRC32C select ZLIB_INFLATE
fs/notify/Kconfig +1 -0
@@ -1,5 +1,6 @@ config FSNOTIFY def_bool n + depends on BROKEN select SRCU source "fs/notify/dnotify/Kconfig"
fs/notify/dnotify/Kconfig +1 -0
@@ -1,5 +1,6 @@ config DNOTIFY bool "Dnotify support" + depends on BROKEN select FSNOTIFY default y help
fs/notify/fanotify/Kconfig +1 -0
@@ -1,5 +1,6 @@ config FANOTIFY bool "Filesystem wide access notification" + depends on BROKEN select FSNOTIFY select ANON_INODES default n
fs/notify/inotify/Kconfig +1 -0
@@ -1,5 +1,6 @@ config INOTIFY_USER bool "Inotify support for userspace" + depends on BROKEN select ANON_INODES select FSNOTIFY default y
fs/quota/Kconfig +1 -0
@@ -4,6 +4,7 @@ config QUOTA bool "Quota support" + depends on BROKEN select QUOTACTL select SRCU help
include/linux/srcu.h +4 -2
@@ -94,9 +94,11 @@ void synchronize_srcu(struct srcu_struct *sp);*/ static inline int srcu_read_lock_held (struct srcu_struct *sp) { -if (!debug_lockdep_rcu_enabled ()) -return 1 ; +#ifdef CONFIG_SRCU return lock_is_held (&sp->dep_map); +#else /* #ifdef CONFIG_PROVE_RCU */ +return 1 ; +#endif /* #else #ifdef CONFIG_PROVE_RCU */ }#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
@@ -157,7 +159,9 @@ static inline int srcu_read_lock(struct
srcu_struct *sp) __acquires(sp)
int retval;
retval = __srcu_read_lock(sp);
+#ifdef CONFIG_SRCU
rcu_lock_acquire(&(sp)->dep_map);
+#endif
return retval;
}
@@ -171,7 +175,9 @@ static inline int srcu_read_lock(struct srcu_struct *sp) __acquires(sp)
static inline void srcu_read_unlock(struct srcu_struct *sp, int idx)
__releases(sp)
{
+#ifdef CONFIG_SRCU
rcu_lock_release(&(sp)->dep_map);
+#endif
__srcu_read_unlock(sp, idx);
}
init/Kconfig +3 -2
@@ -311,12 +311,12 @@ config AUDITSYSCALL config AUDIT_WATCH def_bool y - depends on AUDITSYSCALL + depends on AUDITSYSCALL && BROKEN select FSNOTIFY config AUDIT_TREE def_bool y - depends on AUDITSYSCALL + depends on AUDITSYSCALL && BROKEN select FSNOTIFY source "kernel/irq/Kconfig"
@@ -1443,6 +1443,7 @@ menu "Kernel Performance Events And Counters" config PERF_EVENTS bool "Kernel performance events and counters" default y if PROFILING + depends on BROKEN depends on HAVE_PERF_EVENTS select ANON_INODES select IRQ_WORK
kernel/rcu/Kconfig +2 -0
@@ -51,6 +51,7 @@ config RCU_EXPERT config SRCU bool + depends on BROKEN help This option selects the sleepable version of RCU. This version permits arbitrary sleeping or blocking within RCU read-side critical
@@ -70,6 +71,7 @@ config TREE_SRCU config TASKS_RCU def_bool PREEMPT + depends on BROKEN select SRCU help This option enables a task-based RCU implementation that uses
kernel/rcu/Kconfig.debug +2 -2
@@ -13,7 +13,7 @@ config TORTURE_TEST config RCU_PERF_TEST tristate "performance tests for RCU" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && BROKEN select TORTURE_TEST select SRCU select TASKS_RCU
@@ -30,7 +30,7 @@ config RCU_PERF_TEST config RCU_TORTURE_TEST tristate "torture tests for RCU" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && BROKEN select TORTURE_TEST select SRCU select TASKS_RCU
kernel/trace/Kconfig +2 -1
@@ -131,6 +131,7 @@ if FTRACE config FUNCTION_TRACER bool "Kernel Function Tracer" depends on HAVE_FUNCTION_TRACER + depends on BROKEN || !PREEMPT select KALLSYMS select GENERIC_TRACER select CONTEXT_SWITCH_TRACER
@@ -395,7 +396,7 @@ config BRANCH_TRACER config STACK_TRACER bool "Trace max stack" - depends on HAVE_FUNCTION_TRACER + depends on HAVE_FUNCTION_TRACER && BROKEN select FUNCTION_TRACER select STACKTRACE select KALLSYMS
mm/Kconfig +2 -1
@@ -300,6 +300,7 @@ config VIRT_TO_BUS config MMU_NOTIFIER bool + depends on BROKEN select SRCU config KSM
@@ -706,7 +707,7 @@ config HMM config HMM_MIRROR bool "HMM mirror CPU page table into a device page table" - depends on ARCH_HAS_HMM + depends on ARCH_HAS_HMM && BROKEN select MMU_NOTIFIER select HMM help
security/tomoyo/Kconfig +2 -1
@@ -1,5 +1,6 @@ config SECURITY_TOMOYO - bool "TOMOYO Linux Support" + bool "TOMOYO Linux Support" + depends on BROKEN depends on SECURITY depends on NET select SECURITYFS
Josh Triplett
maintainerQuoted 17 lines · Arnd Bergmann
Quoted 6 lines · Paul E. McKenney
Quoted 2 lines · Arnd Bergmann
Evidently there is at least one driver that uses SRCU but doesn't 'select SRCU' in
Kconfig. There are probably others that just haven't been found.Does adding "select SRCU" on "config
PM_SLEEP" inkernel/power/Kconfigfix this?I'm sure it does, but the point I was making is that we probably have a number of those, and would never find the other ones through the current build test setup.
I've now tried disabling a ridiculous number of options to come up with a setup that never enables SRCU. Interestingly, that also means we don't get the
drivers/base/power/wakeup.cproblem in 'allmodconfig', though I did get a link-time error:
[...]
Quoted 10 lines
Turning off lockdep and kmemleak gives me a working allmodconfig build. I'm doing some more testing on ARM, but it looks like this is a dark corner of the randconfig state space that I'm not sure I want to explore more.
Doing an hour of randconfig builds, I already found exactly two missing 'select SRCU':
ERROR: "
__srcu_read_unlock" [drivers/infiniband/core/ib_uverbs.ko] undefined!drivers/base/power/wakeup.c:68:1: error: type defaults to 'int' in declaration of 'DEFINE_STATIC_SRCU' [-Werror=implicit-int]
I've found that, when trying to make something optional, it doesn't suffice to do randconfigs. You need a configuration with *everything* enabled, except for the option you want to test disabling, and anything that depends on or selects that option. And, conversely, when testing if a specific option has all the dependencies it needs, you want a configuration with that option and its dependencies/selects enabled and everything else disabled.
I wonder how easily we could make a kconfig option for an "all except" or "none except" config? Such an option would read a minimal config snippet containing only specific options, and then act like allyesconfig/allmodconfig/allnoconfig as long as doing so doesn't change anything from the minimal config snippet.
- Josh Triplett
Arnd Bergmann
maintainerQuoted 38 lines · Josh Triplett
Quoted 17 lines · Arnd Bergmann
Quoted 6 lines · Paul E. McKenney
Quoted 2 lines · Arnd Bergmann
Evidently there is at least one driver that uses SRCU but doesn't 'select SRCU' in
Kconfig. There are probably others that just haven't been found.Does adding "select SRCU" on "config
PM_SLEEP" inkernel/power/Kconfigfix this?I'm sure it does, but the point I was making is that we probably have a number of those, and would never find the other ones through the current build test setup.
I've now tried disabling a ridiculous number of options to come up with a setup that never enables SRCU. Interestingly, that also means we don't get the
drivers/base/power/wakeup.cproblem in 'allmodconfig', though I did get a link-time error:[...]
Quoted 10 lines
Turning off lockdep and kmemleak gives me a working allmodconfig build. I'm doing some more testing on ARM, but it looks like this is a dark corner of the randconfig state space that I'm not sure I want to explore more.
Doing an hour of randconfig builds, I already found exactly two missing 'select SRCU':
ERROR: "
__srcu_read_unlock" [drivers/infiniband/core/ib_uverbs.ko] undefined!drivers/base/power/wakeup.c:68:1: error: type defaults to 'int' in declaration of 'DEFINE_STATIC_SRCU' [-Werror=implicit-int]I've found that, when trying to make something optional, it doesn't suffice to do randconfigs. You need a configuration with *everything* enabled, except for the option you want to test disabling, and anything that depends on or selects that option. And, conversely, when testing if a specific option has all the dependencies it needs, you want a configuration with that option and its dependencies/selects enabled and everything else disabled.
Quoted 5 lines
I wonder how easily we could make a kconfig option for an "all except" or "none except" config? Such an option would read a minimal config snippet containing only specific options, and then act like allyesconfig/allmodconfig/allnoconfig as long as doing so doesn't change anything from the minimal config snippet.
Well, that's what I tried with the patch above that marks tons of options as 'BROKEN', leaving all the options that don't select SRCU.
The funny thing is that the "everything but SRCU" config worked just fine, but with the same patch, 'randconfig' failed one out of 10 times ;-)
Arnd
Quoted 55 lines · Arnd Bergmann
Quoted 14 lines · Paul E. McKenney
Quoted 13 lines · Arnd Bergmann
Quoted 3 lines · Arnd Bergmann
That fixed the first warning for me, doing the same thing for all three fixed the rest
Now with my workaround applied and the original randconfig that triggered the failure, I get another problem:
drivers/base/power/wakeup.c:68:1: error: data definition has no type or storage class [-Werror]
DEFINE_STATIC_SRCU(wakeup_srcu);Quoted 5 lines
Quoted 2 lines
Evidently there is at least one driver that uses SRCU but doesn't 'select SRCU' in
Kconfig. There are probably others that just haven't been found.Does adding "select SRCU" on "config
PM_SLEEP" inkernel/power/Kconfigfix this?I'm sure it does, but the point I was making is that we probably have a number of those, and would never find the other ones through the current build test setup.
I've now tried disabling a ridiculous number of options to come up with a setup that never enables SRCU. Interestingly, that also means we don't get the
drivers/base/power/wakeup.cproblem in 'allmodconfig', though I did get a link-time error:
kernel/locking/lockdep.o: In function `lockdep_rcu_suspicious':
lockdep.c:(.text+0x2704): undefined reference torcu_scheduler_active' kernel/rcu/update.o: In functiondebug_lockdep_rcu_enabled':
update.c:(.text+0x40): undefined reference torcu_scheduler_active' kernel/rcu/update.o: In functionrcu_read_lock_bh_held':
update.c:(.text+0xa8): undefined reference torcu_scheduler_active' kernel/rcu/update.o: In functionrcu_read_lock_sched_held':
update.c:(.text+0xce0): undefined reference torcu_scheduler_active' kernel/rcu/update.o: In functionrcu_read_lock_held':
update.c:(.text+0xd40): undefined reference torcu_scheduler_active' kernel/rcu/update.o:update.c:(.text+0x10ac): more undefined references torcu_scheduler_active' followmm/kmemleak.o: In function `kmemleak_scan':
kmemleak.c:(.text+0x1768): undefined reference to__end_ro_after_init' kmemleak.c:(.text+0x176c): undefined reference to__start_ro_after_init' Makefile:1029: recipe for target 'vmlinux' failedTurning off lockdep and kmemleak gives me a working allmodconfig build. I'm doing some more testing on ARM, but it looks like this is a dark corner of the randconfig state space that I'm not sure I want to explore more.
Doing an hour of randconfig builds, I already found exactly two missing 'select SRCU':
Quoted 6 lines
ERROR: "
__srcu_read_unlock" [drivers/infiniband/core/ib_uverbs.ko] undefined!drivers/base/power/wakeup.c:68:1: error: type defaults to 'int' in declaration of 'DEFINE_STATIC_SRCU' [-Werror=implicit-int]See below for my test patch. Without
COMMON_CLK,PM_SLEEPand BLOCK, the number useful configurations is very limited.
Yow!!!
Not sure what to say about strange combinations of Kconfig parameters. We could get into just as much trouble having lots of Kconfig-language restrictions preventing these things as we could having people sometimes randomly running into them.
Thanx, Paul
Quoted 559 lines
Arnd
arch/Kconfig +1
-0@@ -91,6 +91,7 @@ config STATIC_KEYS_SELFTEST config OPTPROBES def_bool y depends on KPROBES && HAVE_OPTPROBES + depends on BROKEN || !PREEMPT select TASKS_RCU if PREEMPT config KPROBES_ON_FTRACEarch/arm/Kconfig +7
-2@@ -330,7 +330,7 @@ choice config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU + depends on MMU && BROKEN select ARM_HAS_SG_CHAIN select ARM_PATCH_PHYS_VIRT select AUTO_ZRELADDR@@ -345,7 +345,7 @@ config ARCH_MULTIPLATFORM config ARM_SINGLE_ARMV7M bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" - depends on !MMU + depends on !MMU && BROKEN select ARM_NVIC select AUTO_ZRELADDR select TIMER_OF@@ -463,6 +463,7 @@ config ARCH_IXP4XX config ARCH_DOVE bool "Marvell Dove" + depends on BROKEN select CPU_PJ4 select GENERIC_CLOCKEVENTS select GPIOLIB@@ -506,6 +507,7 @@ config ARCH_W90X900 config ARCH_LPC32XX bool "NXP LPC32XX" + depends on BROKEN select ARM_AMBA select CLKDEV_LOOKUP select CLKSRC_LPC32XX@@ -522,6 +524,7 @@ config ARCH_LPC32XX config ARCH_PXA bool "PXA2xx/PXA3xx-based" depends on MMU + depends on BROKEN select ARCH_MTD_XIP select ARM_CPU_SUSPEND if PM select AUTO_ZRELADDR@@ -563,6 +566,7 @@ config ARCH_RPC config ARCH_SA1100 bool "SA1100-based" + depends on BROKEN select ARCH_MTD_XIP select ARCH_SPARSEMEM_ENABLE select CLKDEV_LOOKUP@@ -584,6 +588,7 @@ config ARCH_SA1100 config ARCH_S3C24XX bool "Samsung S3C24XX SoCs" + depends on BROKEN select ATAGS select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWMarch/arm/kvm/Kconfig +1
-1@@ -20,7 +20,7 @@ if VIRTUALIZATION config KVM bool "Kernel-based Virtual Machine (KVM) support" - depends on MMU && OF + depends on MMU && OF && BROKEN select PREEMPT_NOTIFIERS select ANON_INODES select ARM_GICblock/Kconfig +1
-0@@ -4,6 +4,7 @@ # menuconfig BLOCK bool "Enable the block layer" if EXPERT + depends on BROKEN default y select SBITMAP select SRCUdrivers/clk/Kconfig +1
-0@@ -8,6 +8,7 @@ config HAVE_CLK_PREPARE config COMMON_CLK bool + depends on BROKEN select HAVE_CLK_PREPARE select CLKDEV_LOOKUP select SRCUdrivers/cpufreq/Kconfig +1
-0@@ -2,6 +2,7 @@ menu "CPU Frequency scaling" config CPU_FREQ bool "CPU Frequency scaling" + depends on BROKEN select SRCU help CPU Frequency scaling allows you to change the clock speed ofdrivers/dax/Kconfig +1
-0@@ -1,5 +1,6 @@ menuconfig DAX tristate "DAX: direct access to differentiated memory" + depends on BROKEN select SRCU default m if NVDIMM_DAXdrivers/devfreq/Kconfig +1
-0@@ -1,5 +1,6 @@ menuconfig PM_DEVFREQ bool "Generic Dynamic Voltage and Frequency Scaling (DVFS) support" + depends on BROKEN select SRCU select PM_OPP helpdrivers/gpu/drm/amd/amdgpu/Kconfig +1
-1@@ -25,7 +25,7 @@ config DRM_AMDGPU_CIK config DRM_AMDGPU_USERPTR bool "Always enable userptr write support" - depends on DRM_AMDGPU + depends on DRM_AMDGPU && BROKEN select MMU_NOTIFIER help This option selects CONFIG_MMU_NOTIFIER if it isn't alreadydrivers/gpu/drm/i915/Kconfig +1
-1@@ -84,7 +84,7 @@ config DRM_I915_COMPRESS_ERROR config DRM_I915_USERPTR bool "Always enable userptr support" - depends on DRM_I915 + depends on DRM_I915 && BROKEN select MMU_NOTIFIER default y helpdrivers/gpu/drm/radeon/Kconfig +1
-1@@ -1,6 +1,6 @@ config DRM_RADEON_USERPTR bool "Always enable userptr support" - depends on DRM_RADEON + depends on DRM_RADEON && BROKEN select MMU_NOTIFIER help This option selects CONFIG_MMU_NOTIFIER if it isn't alreadydrivers/hwtracing/coresight/Kconfig +1
-0@@ -3,6 +3,7 @@ # menuconfig CORESIGHT bool "CoreSight Tracing Support" + depends on BROKEN select ARM_AMBA select PERF_EVENTS helpdrivers/hwtracing/stm/Kconfig +1
-0@@ -1,5 +1,6 @@ config STM tristate "System Trace Module devices" + depends on BROKEN select CONFIGFS_FS select SRCU helpdrivers/infiniband/Kconfig +1
-1@@ -51,7 +51,7 @@ config INFINIBAND_USER_MEM config INFINIBAND_ON_DEMAND_PAGING bool "InfiniBand on-demand paging support" - depends on INFINIBAND_USER_MEM + depends on INFINIBAND_USER_MEM && BROKEN select MMU_NOTIFIER default y ---help---drivers/infiniband/hw/hfi1/Kconfig +1
-1@@ -1,6 +1,6 @@ config INFINIBAND_HFI1 tristate "Intel OPA Gen1 support" - depends on X86_64 && INFINIBAND_RDMAVT && I2C + depends on X86_64 && INFINIBAND_RDMAVT && I2C && BROKEN select MMU_NOTIFIER select CRC32 select I2C_ALGOBITdrivers/iommu/Kconfig +2
-2@@ -128,7 +128,7 @@ config AMD_IOMMU config AMD_IOMMU_V2 tristate "AMD IOMMU Version 2 driver" - depends on AMD_IOMMU + depends on AMD_IOMMU && BROKEN select MMU_NOTIFIER ---help--- This option enables support for the AMD IOMMUv2 features of the IOMMU@@ -154,7 +154,7 @@ config INTEL_IOMMU config INTEL_IOMMU_SVM bool "Support for Shared Virtual Memory with Intel IOMMU" - depends on INTEL_IOMMU && X86 + depends on INTEL_IOMMU && X86 && BROKEN select PCI_PASID select MMU_NOTIFIER helpdrivers/md/Kconfig +1
-1@@ -4,7 +4,7 @@ menuconfig MD bool "Multiple devices driver support (RAID and LVM)" - depends on BLOCK + depends on BLOCK && BROKEN select SRCU help Support multiple physical spindles through a single logical device.drivers/misc/Kconfig +1
-1@@ -284,7 +284,7 @@ config QCOM_COINCELL config SGI_GRU tristate "SGI GRU driver" - depends on X86_UV && SMP + depends on X86_UV && SMP && BROKEN default n select MMU_NOTIFIER ---help---drivers/net/Kconfig +2
-0@@ -238,6 +238,7 @@ config MACSEC config NETCONSOLE tristate "Network console logging support" + depends on BROKEN ---help--- If you want to log kernel messages over the network, enable this. See <file:Documentation/networking/netconsole.txt> for details.@@ -254,6 +255,7 @@ config NETCONSOLE_DYNAMIC config NETPOLL def_bool NETCONSOLE + depends on BROKEN select SRCU config NET_POLL_CONTROLLERdrivers/opp/Kconfig +1
-0@@ -1,5 +1,6 @@ config PM_OPP bool + depends on BROKEN select SRCU ---help--- SOCs have a standard set of tuples consisting of frequency anddrivers/xen/Kconfig +1
-1@@ -146,7 +146,7 @@ config XEN_XENBUS_FRONTEND config XEN_GNTDEV tristate "userspace grant access device driver" - depends on XEN + depends on XEN && BROKEN default m select MMU_NOTIFIER helpfs/btrfs/Kconfig +1
-0@@ -1,5 +1,6 @@ config BTRFS_FS tristate "Btrfs filesystem support" + depends on BROKEN select CRYPTO select CRYPTO_CRC32C select ZLIB_INFLATEfs/notify/Kconfig +1
-0@@ -1,5 +1,6 @@ config FSNOTIFY def_bool n + depends on BROKEN select SRCU source "fs/notify/dnotify/Kconfig"fs/notify/dnotify/Kconfig +1
-0@@ -1,5 +1,6 @@ config DNOTIFY bool "Dnotify support" + depends on BROKEN select FSNOTIFY default y helpfs/notify/fanotify/Kconfig +1
-0@@ -1,5 +1,6 @@ config FANOTIFY bool "Filesystem wide access notification" + depends on BROKEN select FSNOTIFY select ANON_INODES default nfs/notify/inotify/Kconfig +1
-0@@ -1,5 +1,6 @@ config INOTIFY_USER bool "Inotify support for userspace" + depends on BROKEN select ANON_INODES select FSNOTIFY default yfs/quota/Kconfig +1
-0@@ -4,6 +4,7 @@ config QUOTA bool "Quota support" + depends on BROKEN select QUOTACTL select SRCU helpinclude/linux/srcu.h +8
-2@@ -94,9 +94,11 @@ void synchronize_srcu(struct srcu_struct *sp);*/ static inline int srcu_read_lock_held (struct srcu_struct *sp) { -if (!debug_lockdep_rcu_enabled ()) -return 1 ; +#ifdef CONFIG_SRCU return lock_is_held (&sp->dep_map); +#else /* #ifdef CONFIG_PROVE_RCU */ +return 1 ; +#endif /* #else #ifdef CONFIG_PROVE_RCU */ }#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */ @@ -157,7 +159,9 @@ static inline int srcu_read_lock(struct srcu_struct *sp) __acquires(sp) int retval; retval = __srcu_read_lock(sp); +#ifdef CONFIG_SRCU rcu_lock_acquire(&(sp)->dep_map); +#endif return retval; }@@ -171,7 +175,9 @@ static inline int srcu_read_lock(struct srcu_struct *sp) __acquires(sp) static inline void srcu_read_unlock(struct srcu_struct *sp, int idx) __releases(sp) { +#ifdef CONFIG_SRCU rcu_lock_release (&(sp)->dep_map); +#endif __srcu_read_unlock (sp, idx); }init/Kconfig +3
-2@@ -311,12 +311,12 @@ config AUDITSYSCALL config AUDIT_WATCH def_bool y - depends on AUDITSYSCALL + depends on AUDITSYSCALL && BROKEN select FSNOTIFY config AUDIT_TREE def_bool y - depends on AUDITSYSCALL + depends on AUDITSYSCALL && BROKEN select FSNOTIFY source "kernel/irq/Kconfig"@@ -1443,6 +1443,7 @@ menu "Kernel Performance Events And Counters" config PERF_EVENTS bool "Kernel performance events and counters" default y if PROFILING + depends on BROKEN depends on HAVE_PERF_EVENTS select ANON_INODES select IRQ_WORKkernel/rcu/Kconfig +2
-0@@ -51,6 +51,7 @@ config RCU_EXPERT config SRCU bool + depends on BROKEN help This option selects the sleepable version of RCU. This version permits arbitrary sleeping or blocking within RCU read-side critical@@ -70,6 +71,7 @@ config TREE_SRCU config TASKS_RCU def_bool PREEMPT + depends on BROKEN select SRCU help This option enables a task-based RCU implementation that useskernel/rcu/Kconfig.debug +2
-2@@ -13,7 +13,7 @@ config TORTURE_TEST config RCU_PERF_TEST tristate "performance tests for RCU" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && BROKEN select TORTURE_TEST select SRCU select TASKS_RCU@@ -30,7 +30,7 @@ config RCU_PERF_TEST config RCU_TORTURE_TEST tristate "torture tests for RCU" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && BROKEN select TORTURE_TEST select SRCU select TASKS_RCUkernel/trace/Kconfig +2
-1@@ -131,6 +131,7 @@ if FTRACE config FUNCTION_TRACER bool "Kernel Function Tracer" depends on HAVE_FUNCTION_TRACER + depends on BROKEN || !PREEMPT select KALLSYMS select GENERIC_TRACER select CONTEXT_SWITCH_TRACER@@ -395,7 +396,7 @@ config BRANCH_TRACER config STACK_TRACER bool "Trace max stack" - depends on HAVE_FUNCTION_TRACER + depends on HAVE_FUNCTION_TRACER && BROKEN select FUNCTION_TRACER select STACKTRACE select KALLSYMSmm/Kconfig +2
-1@@ -300,6 +300,7 @@ config VIRT_TO_BUS config MMU_NOTIFIER bool + depends on BROKEN select SRCU config KSM@@ -706,7 +707,7 @@ config HMM config HMM_MIRROR bool "HMM mirror CPU page table into a device page table" - depends on ARCH_HAS_HMM + depends on ARCH_HAS_HMM && BROKEN select MMU_NOTIFIER select HMM helpsecurity/tomoyo/Kconfig +2
-1@@ -1,5 +1,6 @@ config SECURITY_TOMOYO - bool "TOMOYO Linux Support" + bool "TOMOYO Linux Support" + depends on BROKEN depends on SECURITY depends on NET select SECURITYFS