Hello, Nicolas!
Saw the TTY write up LWN and figured I should send this your way.
It should be worth about 2K compared to current -next, which gave
up the 2K compared to v4.10. So really getting things back to where
they were.
My current plan is to push this into v4.13.
Thanx, Paul
------------------------------------------------------------------------
commit e01ef0529ed548c1b30206058c2b5eecbbc07998
Author: Paul E. McKenney <[email protected]>
Date: Fri Apr 28 13:53:04 2017 -0700
srcu: Make SRCU be once again optional
Commit d160a727c40e ("srcu: Make SRCU be built by default") in response
to build errors, which were caused by code that included srcu.h
despite !SRCU. However, srcutiny.o is almost 2K of code, which is not
insignificant for those attempting to run the Linux kernel on IoT devices.
This commit therefore makes SRCU be once again optional, and adjusts
srcu.h to allow error-free inclusion in !SRCU kernel builds.
Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Nicolas Pitre <[email protected]>
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
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 <[email protected]>
> Date: Fri Apr 28 13:53:04 2017 -0700
>
> srcu: Make SRCU be once again optional
>
> Commit d160a727c40e ("srcu: Make SRCU be built by default") in response
> to build errors, which were caused by code that included srcu.h
> despite !SRCU. However, srcutiny.o is almost 2K of code, which is not
> insignificant for those attempting to run the Linux kernel on IoT devices.
> This commit therefore makes SRCU be once again optional, and adjusts
> srcu.h to allow error-free inclusion in !SRCU kernel builds.
>
> Signed-off-by: Paul E. McKenney <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
>
> 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
>
>
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 <[email protected]>
> > Date: Fri Apr 28 13:53:04 2017 -0700
> >
> > srcu: Make SRCU be once again optional
> >
> > Commit d160a727c40e ("srcu: Make SRCU be built by default") in response
> > to build errors, which were caused by code that included srcu.h
> > despite !SRCU. However, srcutiny.o is almost 2K of code, which is not
> > insignificant for those attempting to run the Linux kernel on IoT devices.
> > This commit therefore makes SRCU be once again optional, and adjusts
> > srcu.h to allow error-free inclusion in !SRCU kernel builds.
> >
> > Signed-off-by: Paul E. McKenney <[email protected]>
> > Cc: Nicolas Pitre <[email protected]>
>
> Acked-by: Nicolas Pitre <[email protected]>
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
> >
> >
>
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
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
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
On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney
<[email protected]> 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
On Tue, Jan 16, 2018 at 10:02 PM, Arnd Bergmann <[email protected]> wrote:
> On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney
> <[email protected]> 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
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
> <[email protected]> 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 */
On Tue, Jan 16, 2018 at 11:34 PM, Paul E. McKenney
<[email protected]> 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
>> <[email protected]> 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);
}
On Tue, Jan 16, 2018 at 11:55 PM, Arnd Bergmann <[email protected]> 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
On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote:
> On Tue, Jan 16, 2018 at 11:55 PM, Arnd Bergmann <[email protected]> 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
On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney
<[email protected]> 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 <[email protected]> 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
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
> <[email protected]> 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
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
> <[email protected]> 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 <[email protected]> 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
>
On Wed, Jan 17, 2018 at 5:32 PM, Josh Triplett <[email protected]> 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
>> <[email protected]> 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