[PATCH RFC tip/core/rcu] Make SRCU be once again optional

[PATCH RFC tip/core/rcu] Make SRCU be once again optional

[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.

							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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Nicolas Pitre]

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
> 
> 

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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
> > 
> > 
> 

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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
> > > 
> > > 
> > 

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Nicolas Pitre]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Nicolas Pitre]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Arnd Bergmann]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Arnd Bergmann]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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 */

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Arnd Bergmann]

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);
 }

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Arnd Bergmann]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Arnd Bergmann]

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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[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:
> >> 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

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Paul E. McKenney]

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
> 

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

[Arnd Bergmann]

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