* [PATCH RFC tip/core/rcu] Make SRCU be once again optional @ 2017-04-28 21:15 Paul E. McKenney 2017-04-28 21:51 ` Nicolas Pitre 0 siblings, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2017-04-28 21:15 UTC (permalink / raw) To: nicolas.pitre; +Cc: linux-kernel 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 <paulmck@linux.vnet.ibm.com> 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. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> diff --git a/include/linux/srcu.h b/include/linux/srcu.h index 167ad8831aaf..c0143fe2e39d 100644 --- a/include/linux/srcu.h +++ b/include/linux/srcu.h @@ -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 diff --git a/init/Kconfig b/init/Kconfig index 42a346b0df43..fe72c12e06a5 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -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 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-04-28 21:15 [PATCH RFC tip/core/rcu] Make SRCU be once again optional Paul E. McKenney @ 2017-04-28 21:51 ` Nicolas Pitre 2017-04-29 0:10 ` Paul E. McKenney 0 siblings, 1 reply; 20+ messages in thread From: Nicolas Pitre @ 2017-04-28 21:51 UTC (permalink / raw) To: Paul E. McKenney; +Cc: linux-kernel On Fri, 28 Apr 2017, Paul E. McKenney wrote: > 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. > > Thanx, Paul > > ------------------------------------------------------------------------ > > commit e01ef0529ed548c1b30206058c2b5eecbbc07998 > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > 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. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> > > diff --git a/include/linux/srcu.h b/include/linux/srcu.h > index 167ad8831aaf..c0143fe2e39d 100644 > --- a/include/linux/srcu.h > +++ b/include/linux/srcu.h > @@ -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 > > diff --git a/init/Kconfig b/init/Kconfig > index 42a346b0df43..fe72c12e06a5 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -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 > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-04-28 21:51 ` Nicolas Pitre @ 2017-04-29 0:10 ` Paul E. McKenney 2017-05-12 18:41 ` Paul E. McKenney 0 siblings, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2017-04-29 0:10 UTC (permalink / raw) To: Nicolas Pitre; +Cc: linux-kernel On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > 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. 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! ;-) > > ------------------------------------------------------------------------ > > > > commit e01ef0529ed548c1b30206058c2b5eecbbc07998 > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > 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. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Cc: Nicolas Pitre <nicolas.pitre@linaro.org> > > Acked-by: Nicolas Pitre <nico@linaro.org> Applied, thank you! Thanx, Paul > > diff --git a/include/linux/srcu.h b/include/linux/srcu.h > > index 167ad8831aaf..c0143fe2e39d 100644 > > --- a/include/linux/srcu.h > > +++ b/include/linux/srcu.h > > @@ -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 > > > > diff --git a/init/Kconfig b/init/Kconfig > > index 42a346b0df43..fe72c12e06a5 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -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 > > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-04-29 0:10 ` Paul E. McKenney @ 2017-05-12 18:41 ` Paul E. McKenney 2017-05-12 18:45 ` Paul E. McKenney 2017-05-12 18:59 ` Nicolas Pitre 0 siblings, 2 replies; 20+ messages in thread From: Paul E. McKenney @ 2017-05-12 18:41 UTC (permalink / raw) To: Nicolas Pitre; +Cc: linux-kernel On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > 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. > > 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 > > > ------------------------------------------------------------------------ > > > > > > commit e01ef0529ed548c1b30206058c2b5eecbbc07998 > > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > 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. > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > Cc: Nicolas Pitre <nicolas.pitre@linaro.org> > > > > Acked-by: Nicolas Pitre <nico@linaro.org> > > Applied, thank you! > > Thanx, Paul > > > > diff --git a/include/linux/srcu.h b/include/linux/srcu.h > > > index 167ad8831aaf..c0143fe2e39d 100644 > > > --- a/include/linux/srcu.h > > > +++ b/include/linux/srcu.h > > > @@ -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 > > > > > > diff --git a/init/Kconfig b/init/Kconfig > > > index 42a346b0df43..fe72c12e06a5 100644 > > > --- a/init/Kconfig > > > +++ b/init/Kconfig > > > @@ -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 > > > > > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-05-12 18:41 ` Paul E. McKenney @ 2017-05-12 18:45 ` Paul E. McKenney 2017-05-12 18:59 ` Nicolas Pitre 1 sibling, 0 replies; 20+ messages in thread From: Paul E. McKenney @ 2017-05-12 18:45 UTC (permalink / raw) To: Nicolas Pitre; +Cc: linux-kernel, josh On Fri, May 12, 2017 at 11:41:55AM -0700, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > 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. > > > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-05-12 18:41 ` Paul E. McKenney 2017-05-12 18:45 ` Paul E. McKenney @ 2017-05-12 18:59 ` Nicolas Pitre 2017-05-12 19:10 ` Paul E. McKenney 1 sibling, 1 reply; 20+ messages in thread From: Nicolas Pitre @ 2017-05-12 18:59 UTC (permalink / raw) To: Paul E. McKenney; +Cc: linux-kernel On Fri, 12 May 2017, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > 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. > > > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-05-12 18:59 ` Nicolas Pitre @ 2017-05-12 19:10 ` Paul E. McKenney 2017-06-03 3:59 ` Paul E. McKenney 0 siblings, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2017-05-12 19:10 UTC (permalink / raw) To: Nicolas Pitre; +Cc: linux-kernel, josh On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > On Fri, 12 May 2017, Paul E. McKenney wrote: > > > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > > > 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. > > > > > > 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. OK, then wish me luck. ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-05-12 19:10 ` Paul E. McKenney @ 2017-06-03 3:59 ` Paul E. McKenney 2017-06-03 5:18 ` Nicolas Pitre 0 siblings, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2017-06-03 3:59 UTC (permalink / raw) To: Nicolas Pitre; +Cc: linux-kernel, josh On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > On Fri, 12 May 2017, Paul E. McKenney wrote: [ . . . ] > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-06-03 3:59 ` Paul E. McKenney @ 2017-06-03 5:18 ` Nicolas Pitre 2017-06-03 20:36 ` Paul E. McKenney 0 siblings, 1 reply; 20+ messages in thread From: Nicolas Pitre @ 2017-06-03 5:18 UTC (permalink / raw) To: Paul E. McKenney; +Cc: linux-kernel, josh On Fri, 2 Jun 2017, Paul E. McKenney wrote: > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > > On Fri, 12 May 2017, Paul E. McKenney wrote: > > [ . . . ] > > > > 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. 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-06-03 5:18 ` Nicolas Pitre @ 2017-06-03 20:36 ` Paul E. McKenney 2018-01-16 21:02 ` Arnd Bergmann 0 siblings, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2017-06-03 20:36 UTC (permalink / raw) To: Nicolas Pitre; +Cc: linux-kernel, josh On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: > On Fri, 2 Jun 2017, Paul E. McKenney wrote: > > > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > > > On Fri, 12 May 2017, Paul E. McKenney wrote: > > > > [ . . . ] > > > > > > 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. > > 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 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2017-06-03 20:36 ` Paul E. McKenney @ 2018-01-16 21:02 ` Arnd Bergmann 2018-01-16 21:10 ` Arnd Bergmann 2018-01-16 22:34 ` Paul E. McKenney 0 siblings, 2 replies; 20+ messages in thread From: Arnd Bergmann @ 2018-01-16 21:02 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >> On Fri, 2 Jun 2017, Paul E. McKenney wrote: >> >> > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: >> > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: >> > > > On Fri, 12 May 2017, Paul E. McKenney wrote: >> > >> > [ . . . ] >> > >> > > > 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. >> >> 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 > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-16 21:02 ` Arnd Bergmann @ 2018-01-16 21:10 ` Arnd Bergmann 2018-01-16 22:34 ` Paul E. McKenney 1 sibling, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2018-01-16 21:10 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Tue, Jan 16, 2018 at 10:02 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: >> On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >>> 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: https://pastebin.com/Xc0exzfg Arnd ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-16 21:02 ` Arnd Bergmann 2018-01-16 21:10 ` Arnd Bergmann @ 2018-01-16 22:34 ` Paul E. McKenney 2018-01-16 22:55 ` Arnd Bergmann 1 sibling, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2018-01-16 22:34 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Tue, Jan 16, 2018 at 10:02:10PM +0100, Arnd Bergmann wrote: > On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: > >> On Fri, 2 Jun 2017, Paul E. McKenney wrote: > >> > >> > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > >> > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > >> > > > On Fri, 12 May 2017, Paul E. McKenney wrote: > >> > > >> > [ . . . ] > >> > > >> > > > 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. > >> > >> 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 > > > > 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: Yow!!! I am impressed! > 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? > ./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); > ^~ 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.) > 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. 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 ------------------------------------------------------------------------ diff --git a/include/linux/srcu.h b/include/linux/srcu.h index 62be8966e837..b4fd484ad6cb 100644 --- a/include/linux/srcu.h +++ b/include/linux/srcu.h @@ -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 */ ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-16 22:34 ` Paul E. McKenney @ 2018-01-16 22:55 ` Arnd Bergmann 2018-01-16 23:03 ` Arnd Bergmann 0 siblings, 1 reply; 20+ messages in thread From: Arnd Bergmann @ 2018-01-16 22:55 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Tue, Jan 16, 2018 at 11:34 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Tue, Jan 16, 2018 at 10:02:10PM +0100, Arnd Bergmann wrote: >> On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney >> <paulmck@linux.vnet.ibm.com> wrote: >> > On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >> >> On Fri, 2 Jun 2017, Paul E. McKenney wrote: >> >> >> >> > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: >> >> > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: >> >> > > > On Fri, 12 May 2017, Paul E. McKenney wrote: >> >> > >> >> > [ . . . ] >> >> > >> >> > > > 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. >> >> >> >> 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 >> > >> > 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: > > Yow!!! I am impressed! > >> 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? > >> ./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); >> ^~ > > 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 set CONFIG_DEBUG_LOCK_ALLOC=y > diff --git a/include/linux/srcu.h b/include/linux/srcu.h > index 62be8966e837..b4fd484ad6cb 100644 > --- a/include/linux/srcu.h > +++ b/include/linux/srcu.h > @@ -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 */ That fixed the first warning for me, doing the same thing for all three fixed the rest: diff --git a/include/linux/srcu.h b/include/linux/srcu.h index 62be8966e837..1bab741b384b 100644 --- a/include/linux/srcu.h +++ b/include/linux/srcu.h @@ -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); } ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-16 22:55 ` Arnd Bergmann @ 2018-01-16 23:03 ` Arnd Bergmann 2018-01-16 23:57 ` Paul E. McKenney 0 siblings, 1 reply; 20+ messages in thread From: Arnd Bergmann @ 2018-01-16 23:03 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Tue, Jan 16, 2018 at 11:55 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-16 23:03 ` Arnd Bergmann @ 2018-01-16 23:57 ` Paul E. McKenney 2018-01-17 10:29 ` Arnd Bergmann 0 siblings, 1 reply; 20+ messages in thread From: Paul E. McKenney @ 2018-01-16 23:57 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote: > On Tue, Jan 16, 2018 at 11:55 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > > > > 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. Does adding "select SRCU" on "config PM_SLEEP" in kernel/power/Kconfig fix this? Thanx, Paul ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-16 23:57 ` Paul E. McKenney @ 2018-01-17 10:29 ` Arnd Bergmann 2018-01-17 16:32 ` Josh Triplett 2018-01-17 16:47 ` Paul E. McKenney 0 siblings, 2 replies; 20+ messages in thread From: Arnd Bergmann @ 2018-01-17 10:29 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote: >> On Tue, Jan 16, 2018 at 11:55 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> >> > >> > 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. > > Does adding "select SRCU" on "config PM_SLEEP" in kernel/power/Kconfig > fix 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' follow mm/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 diff --git a/arch/Kconfig b/arch/Kconfig index 9ba8c3df9ff6..d1b0ac3c9f4d 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -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 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3d349b4f709e..ba397fc7e9d5 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -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 diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index e2bd35b6780c..b29a10a80d97 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -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 diff --git a/block/Kconfig b/block/Kconfig index 28ec55752b68..c3d807fa91b6 100644 --- a/block/Kconfig +++ b/block/Kconfig @@ -4,6 +4,7 @@ # menuconfig BLOCK bool "Enable the block layer" if EXPERT + depends on BROKEN default y select SBITMAP select SRCU diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 98ce9fc6e6c0..07fdc293134d 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -8,6 +8,7 @@ config HAVE_CLK_PREPARE config COMMON_CLK bool + depends on BROKEN select HAVE_CLK_PREPARE select CLKDEV_LOOKUP select SRCU diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index d8addbce40bc..244b4c241811 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -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 diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig index b79aa8f7a497..efd94826c020 100644 --- a/drivers/dax/Kconfig +++ b/drivers/dax/Kconfig @@ -1,5 +1,6 @@ menuconfig DAX tristate "DAX: direct access to differentiated memory" + depends on BROKEN select SRCU default m if NVDIMM_DAX diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index 6a172d338f6d..cd67f2ac8803 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -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 diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index e8af1f5e8a79..20d3bcd5a638 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -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 diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index dfd95889f4b7..a8db7a547aab 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -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 diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 9909f5c68d76..34e1aaa60abd 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -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 diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig index ef9cb3c164e1..ea6da47c136a 100644 --- a/drivers/hwtracing/coresight/Kconfig +++ b/drivers/hwtracing/coresight/Kconfig @@ -3,6 +3,7 @@ # menuconfig CORESIGHT bool "CoreSight Tracing Support" + depends on BROKEN select ARM_AMBA select PERF_EVENTS help diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig index 723e2d90083d..0e0080d28ad5 100644 --- a/drivers/hwtracing/stm/Kconfig +++ b/drivers/hwtracing/stm/Kconfig @@ -1,5 +1,6 @@ config STM tristate "System Trace Module devices" + depends on BROKEN select CONFIGFS_FS select SRCU help diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig index 5cd700421695..f64fe02a5858 100644 --- a/drivers/infiniband/Kconfig +++ b/drivers/infiniband/Kconfig @@ -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--- diff --git a/drivers/infiniband/hw/hfi1/Kconfig b/drivers/infiniband/hw/hfi1/Kconfig index 7b146b67a80f..b41fd3506be9 100644 --- a/drivers/infiniband/hw/hfi1/Kconfig +++ b/drivers/infiniband/hw/hfi1/Kconfig @@ -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 diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index f3a21343e636..48c4d5a321da 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -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 diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 2c8ac3688815..8b0ae082872a 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -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. diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 7c0fa24f9067..eea5f553860a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -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--- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 944ec3c9282c..bba60a8fd482 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -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 diff --git a/drivers/opp/Kconfig b/drivers/opp/Kconfig index a7fbb93f302c..06894a6fa24c 100644 --- a/drivers/opp/Kconfig +++ b/drivers/opp/Kconfig @@ -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 diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index e5d0c28372ea..9761331e0505 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -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 diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig index 273351ee4c46..66a0d7688630 100644 --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -1,5 +1,6 @@ config BTRFS_FS tristate "Btrfs filesystem support" + depends on BROKEN select CRYPTO select CRYPTO_CRC32C select ZLIB_INFLATE diff --git a/fs/notify/Kconfig b/fs/notify/Kconfig index 2a24249b30af..598ceab78b62 100644 --- a/fs/notify/Kconfig +++ b/fs/notify/Kconfig @@ -1,5 +1,6 @@ config FSNOTIFY def_bool n + depends on BROKEN select SRCU source "fs/notify/dnotify/Kconfig" diff --git a/fs/notify/dnotify/Kconfig b/fs/notify/dnotify/Kconfig index f9c1ca139d8f..f6964a9a5eb9 100644 --- a/fs/notify/dnotify/Kconfig +++ b/fs/notify/dnotify/Kconfig @@ -1,5 +1,6 @@ config DNOTIFY bool "Dnotify support" + depends on BROKEN select FSNOTIFY default y help diff --git a/fs/notify/fanotify/Kconfig b/fs/notify/fanotify/Kconfig index 41355ce74ac0..fcb2edd643d4 100644 --- a/fs/notify/fanotify/Kconfig +++ b/fs/notify/fanotify/Kconfig @@ -1,5 +1,6 @@ config FANOTIFY bool "Filesystem wide access notification" + depends on BROKEN select FSNOTIFY select ANON_INODES default n diff --git a/fs/notify/inotify/Kconfig b/fs/notify/inotify/Kconfig index b981fc0c8379..916cbd5569fa 100644 --- a/fs/notify/inotify/Kconfig +++ b/fs/notify/inotify/Kconfig @@ -1,5 +1,6 @@ config INOTIFY_USER bool "Inotify support for userspace" + depends on BROKEN select ANON_INODES select FSNOTIFY default y diff --git a/fs/quota/Kconfig b/fs/quota/Kconfig index 4a09975aac90..dbf3f3cdcbd8 100644 --- a/fs/quota/Kconfig +++ b/fs/quota/Kconfig @@ -4,6 +4,7 @@ config QUOTA bool "Quota support" + depends on BROKEN select QUOTACTL select SRCU help diff --git a/include/linux/srcu.h b/include/linux/srcu.h index 62be8966e837..587128fcec05 100644 --- a/include/linux/srcu.h +++ b/include/linux/srcu.h @@ -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); } diff --git a/init/Kconfig b/init/Kconfig index a9a2e2c86671..b68adf1b1373 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -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 diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 9210379c0353..4df64e8ca66a 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -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 diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug index 0ec7d1d33a14..a66eb614ae39 100644 --- a/kernel/rcu/Kconfig.debug +++ b/kernel/rcu/Kconfig.debug @@ -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 diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 7114c885a78a..b52390595727 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -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 diff --git a/mm/Kconfig b/mm/Kconfig index c782e8fb7235..17c9e82935da 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -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 diff --git a/security/tomoyo/Kconfig b/security/tomoyo/Kconfig index 404dce66952a..3a664764fb19 100644 --- a/security/tomoyo/Kconfig +++ b/security/tomoyo/Kconfig @@ -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 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-17 10:29 ` Arnd Bergmann @ 2018-01-17 16:32 ` Josh Triplett 2018-01-17 17:10 ` Arnd Bergmann 2018-01-17 16:47 ` Paul E. McKenney 1 sibling, 1 reply; 20+ messages in thread From: Josh Triplett @ 2018-01-17 16:32 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Paul E. McKenney, Nicolas Pitre, Linux Kernel Mailing List On Wed, Jan 17, 2018 at 11:29:26AM +0100, Arnd Bergmann wrote: > On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote: > >> 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? > > 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: [...] > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-17 16:32 ` Josh Triplett @ 2018-01-17 17:10 ` Arnd Bergmann 0 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2018-01-17 17:10 UTC (permalink / raw) To: Josh Triplett; +Cc: Paul E. McKenney, Nicolas Pitre, Linux Kernel Mailing List On Wed, Jan 17, 2018 at 5:32 PM, Josh Triplett <josh@joshtriplett.org> wrote: > On Wed, Jan 17, 2018 at 11:29:26AM +0100, Arnd Bergmann wrote: >> On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney >> <paulmck@linux.vnet.ibm.com> wrote: >> > On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote: >> >> 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? >> >> 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: > [...] >> 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. 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional 2018-01-17 10:29 ` Arnd Bergmann 2018-01-17 16:32 ` Josh Triplett @ 2018-01-17 16:47 ` Paul E. McKenney 1 sibling, 0 replies; 20+ messages in thread From: Paul E. McKenney @ 2018-01-17 16:47 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Nicolas Pitre, Linux Kernel Mailing List, Josh Triplett On Wed, Jan 17, 2018 at 11:29:26AM +0100, Arnd Bergmann wrote: > On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote: > >> On Tue, Jan 16, 2018 at 11:55 PM, Arnd Bergmann <arnd@arndb.de> wrote: > >> > >> > > >> > 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. > > > > Does adding "select SRCU" on "config PM_SLEEP" in kernel/power/Kconfig > > fix 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' follow > mm/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. 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 > Arnd > > diff --git a/arch/Kconfig b/arch/Kconfig > index 9ba8c3df9ff6..d1b0ac3c9f4d 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -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 > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3d349b4f709e..ba397fc7e9d5 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 > diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig > index e2bd35b6780c..b29a10a80d97 100644 > --- a/arch/arm/kvm/Kconfig > +++ b/arch/arm/kvm/Kconfig > @@ -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 > diff --git a/block/Kconfig b/block/Kconfig > index 28ec55752b68..c3d807fa91b6 100644 > --- a/block/Kconfig > +++ b/block/Kconfig > @@ -4,6 +4,7 @@ > # > menuconfig BLOCK > bool "Enable the block layer" if EXPERT > + depends on BROKEN > default y > select SBITMAP > select SRCU > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > index 98ce9fc6e6c0..07fdc293134d 100644 > --- a/drivers/clk/Kconfig > +++ b/drivers/clk/Kconfig > @@ -8,6 +8,7 @@ config HAVE_CLK_PREPARE > > config COMMON_CLK > bool > + depends on BROKEN > select HAVE_CLK_PREPARE > select CLKDEV_LOOKUP > select SRCU > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index d8addbce40bc..244b4c241811 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -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 > diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig > index b79aa8f7a497..efd94826c020 100644 > --- a/drivers/dax/Kconfig > +++ b/drivers/dax/Kconfig > @@ -1,5 +1,6 @@ > menuconfig DAX > tristate "DAX: direct access to differentiated memory" > + depends on BROKEN > select SRCU > default m if NVDIMM_DAX > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index 6a172d338f6d..cd67f2ac8803 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -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 > diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig > b/drivers/gpu/drm/amd/amdgpu/Kconfig > index e8af1f5e8a79..20d3bcd5a638 100644 > --- a/drivers/gpu/drm/amd/amdgpu/Kconfig > +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig > @@ -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 > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index dfd95889f4b7..a8db7a547aab 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -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 > diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig > index 9909f5c68d76..34e1aaa60abd 100644 > --- a/drivers/gpu/drm/radeon/Kconfig > +++ b/drivers/gpu/drm/radeon/Kconfig > @@ -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 > diff --git a/drivers/hwtracing/coresight/Kconfig > b/drivers/hwtracing/coresight/Kconfig > index ef9cb3c164e1..ea6da47c136a 100644 > --- a/drivers/hwtracing/coresight/Kconfig > +++ b/drivers/hwtracing/coresight/Kconfig > @@ -3,6 +3,7 @@ > # > menuconfig CORESIGHT > bool "CoreSight Tracing Support" > + depends on BROKEN > select ARM_AMBA > select PERF_EVENTS > help > diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig > index 723e2d90083d..0e0080d28ad5 100644 > --- a/drivers/hwtracing/stm/Kconfig > +++ b/drivers/hwtracing/stm/Kconfig > @@ -1,5 +1,6 @@ > config STM > tristate "System Trace Module devices" > + depends on BROKEN > select CONFIGFS_FS > select SRCU > help > diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig > index 5cd700421695..f64fe02a5858 100644 > --- a/drivers/infiniband/Kconfig > +++ b/drivers/infiniband/Kconfig > @@ -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--- > diff --git a/drivers/infiniband/hw/hfi1/Kconfig > b/drivers/infiniband/hw/hfi1/Kconfig > index 7b146b67a80f..b41fd3506be9 100644 > --- a/drivers/infiniband/hw/hfi1/Kconfig > +++ b/drivers/infiniband/hw/hfi1/Kconfig > @@ -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 > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index f3a21343e636..48c4d5a321da 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -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 > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > index 2c8ac3688815..8b0ae082872a 100644 > --- a/drivers/md/Kconfig > +++ b/drivers/md/Kconfig > @@ -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. > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 7c0fa24f9067..eea5f553860a 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -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--- > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index 944ec3c9282c..bba60a8fd482 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -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 > diff --git a/drivers/opp/Kconfig b/drivers/opp/Kconfig > index a7fbb93f302c..06894a6fa24c 100644 > --- a/drivers/opp/Kconfig > +++ b/drivers/opp/Kconfig > @@ -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 > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index e5d0c28372ea..9761331e0505 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -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 > diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig > index 273351ee4c46..66a0d7688630 100644 > --- a/fs/btrfs/Kconfig > +++ b/fs/btrfs/Kconfig > @@ -1,5 +1,6 @@ > config BTRFS_FS > tristate "Btrfs filesystem support" > + depends on BROKEN > select CRYPTO > select CRYPTO_CRC32C > select ZLIB_INFLATE > diff --git a/fs/notify/Kconfig b/fs/notify/Kconfig > index 2a24249b30af..598ceab78b62 100644 > --- a/fs/notify/Kconfig > +++ b/fs/notify/Kconfig > @@ -1,5 +1,6 @@ > config FSNOTIFY > def_bool n > + depends on BROKEN > select SRCU > > source "fs/notify/dnotify/Kconfig" > diff --git a/fs/notify/dnotify/Kconfig b/fs/notify/dnotify/Kconfig > index f9c1ca139d8f..f6964a9a5eb9 100644 > --- a/fs/notify/dnotify/Kconfig > +++ b/fs/notify/dnotify/Kconfig > @@ -1,5 +1,6 @@ > config DNOTIFY > bool "Dnotify support" > + depends on BROKEN > select FSNOTIFY > default y > help > diff --git a/fs/notify/fanotify/Kconfig b/fs/notify/fanotify/Kconfig > index 41355ce74ac0..fcb2edd643d4 100644 > --- a/fs/notify/fanotify/Kconfig > +++ b/fs/notify/fanotify/Kconfig > @@ -1,5 +1,6 @@ > config FANOTIFY > bool "Filesystem wide access notification" > + depends on BROKEN > select FSNOTIFY > select ANON_INODES > default n > diff --git a/fs/notify/inotify/Kconfig b/fs/notify/inotify/Kconfig > index b981fc0c8379..916cbd5569fa 100644 > --- a/fs/notify/inotify/Kconfig > +++ b/fs/notify/inotify/Kconfig > @@ -1,5 +1,6 @@ > config INOTIFY_USER > bool "Inotify support for userspace" > + depends on BROKEN > select ANON_INODES > select FSNOTIFY > default y > diff --git a/fs/quota/Kconfig b/fs/quota/Kconfig > index 4a09975aac90..dbf3f3cdcbd8 100644 > --- a/fs/quota/Kconfig > +++ b/fs/quota/Kconfig > @@ -4,6 +4,7 @@ > > config QUOTA > bool "Quota support" > + depends on BROKEN > select QUOTACTL > select SRCU > help > diff --git a/include/linux/srcu.h b/include/linux/srcu.h > index 62be8966e837..587128fcec05 100644 > --- a/include/linux/srcu.h > +++ b/include/linux/srcu.h > @@ -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); > } > > diff --git a/init/Kconfig b/init/Kconfig > index a9a2e2c86671..b68adf1b1373 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -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 > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > index 9210379c0353..4df64e8ca66a 100644 > --- a/kernel/rcu/Kconfig > +++ b/kernel/rcu/Kconfig > @@ -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 > diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug > index 0ec7d1d33a14..a66eb614ae39 100644 > --- a/kernel/rcu/Kconfig.debug > +++ b/kernel/rcu/Kconfig.debug > @@ -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 > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index 7114c885a78a..b52390595727 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -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 > diff --git a/mm/Kconfig b/mm/Kconfig > index c782e8fb7235..17c9e82935da 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -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 > diff --git a/security/tomoyo/Kconfig b/security/tomoyo/Kconfig > index 404dce66952a..3a664764fb19 100644 > --- a/security/tomoyo/Kconfig > +++ b/security/tomoyo/Kconfig > @@ -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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-01-17 17:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-28 21:15 [PATCH RFC tip/core/rcu] Make SRCU be once again optional Paul E. McKenney 2017-04-28 21:51 ` Nicolas Pitre 2017-04-29 0:10 ` Paul E. McKenney 2017-05-12 18:41 ` Paul E. McKenney 2017-05-12 18:45 ` Paul E. McKenney 2017-05-12 18:59 ` Nicolas Pitre 2017-05-12 19:10 ` Paul E. McKenney 2017-06-03 3:59 ` Paul E. McKenney 2017-06-03 5:18 ` Nicolas Pitre 2017-06-03 20:36 ` Paul E. McKenney 2018-01-16 21:02 ` Arnd Bergmann 2018-01-16 21:10 ` Arnd Bergmann 2018-01-16 22:34 ` Paul E. McKenney 2018-01-16 22:55 ` Arnd Bergmann 2018-01-16 23:03 ` Arnd Bergmann 2018-01-16 23:57 ` Paul E. McKenney 2018-01-17 10:29 ` Arnd Bergmann 2018-01-17 16:32 ` Josh Triplett 2018-01-17 17:10 ` Arnd Bergmann 2018-01-17 16:47 ` Paul E. McKenney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).