next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Naresh Kamboju]

Today's Linux next 20221122 tag clang-15 tinyconfig builds fails on
powerpc and s390 architectures.

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/build LLVM_IAS=0 ARCH=s390
CROSS_COMPILE=s390x-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
clang'

kernel/printk/printk.c:95:1: error: type specifier missing, defaults
to 'int'; ISO C99 and later do not support implicit int
[-Werror,-Wimplicit-int]
DEFINE_STATIC_SRCU(console_srcu);
^
int
kernel/printk/printk.c:95:20: error: a parameter list without types is
only allowed in a function definition
DEFINE_STATIC_SRCU(console_srcu);
                   ^
kernel/printk/printk.c:261:29: error: use of undeclared identifier
'console_srcu'
                     srcu_read_lock_held(&console_srcu));
                                          ^
kernel/printk/printk.c:288:33: error: use of undeclared identifier
'console_srcu'
        return srcu_read_lock_nmisafe(&console_srcu);
                                       ^
kernel/printk/printk.c:300:28: error: use of undeclared identifier
'console_srcu'
        srcu_read_unlock_nmisafe(&console_srcu, cookie);
                                  ^
kernel/printk/printk.c:3122:20: error: use of undeclared identifier
'console_srcu'
        synchronize_srcu(&console_srcu);
                          ^
kernel/printk/printk.c:3469:20: error: use of undeclared identifier
'console_srcu'
        synchronize_srcu(&console_srcu);
                          ^
kernel/printk/printk.c:3521:20: error: use of undeclared identifier
'console_srcu'
        synchronize_srcu(&console_srcu);
                          ^
8 errors generated.

log:
https://builds.tuxbuild.com/2HtTqOb2b83eGTzpS4bjLf59Agd/

Build history:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221122/testrun/13121925/suite/build/test/clang-15-tinyconfig/history/

--
Linaro LKFT
https://lkft.linaro.org

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[John Ogness]

Hi Petr,

On 2022-11-22, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> Today's Linux next 20221122 tag clang-15 tinyconfig builds fails on
> powerpc and s390 architectures.

The problem is that CONFIG_SRCU is not selected. This must be selected
by any modules that requires SRCU. However, printk.c is _always_ built
into the kernel (even if !CONFIG_PRINTK). The registration of consoles
and the console list (which uses SRCU) is _always_ built into the
kernel.

So should CONFIG_SRCU now always be active?

@paulmck: Do you have a problem with permanently activating CONFIG_SRCU?

John Ogness

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Tue, Nov 22, 2022 at 03:33:16PM +0106, John Ogness wrote:
> Hi Petr,
> 
> On 2022-11-22, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > Today's Linux next 20221122 tag clang-15 tinyconfig builds fails on
> > powerpc and s390 architectures.
> 
> The problem is that CONFIG_SRCU is not selected. This must be selected
> by any modules that requires SRCU. However, printk.c is _always_ built
> into the kernel (even if !CONFIG_PRINTK). The registration of consoles
> and the console list (which uses SRCU) is _always_ built into the
> kernel.
> 
> So should CONFIG_SRCU now always be active?
> 
> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?

The people wanting it separate back in the day were those wanting very
tiny kernels.  I have not heard from them in a long time, so maybe it
is now OK to just make SRCU unconditional.

							Thanx, Paul

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[John Ogness]

On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
>> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?
>
> The people wanting it separate back in the day were those wanting very
> tiny kernels.  I have not heard from them in a long time, so maybe it
> is now OK to just make SRCU unconditional.

Who decides this? Or maybe I should create a semaphore-based Variant of
console_srcu_read_lock()/console_srcu_read_unlock() for the
"!CONFIG_PRINTK && !CONFIG_SRCU" case?

John

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Petr Mladek]

On Tue 2022-11-22 16:33:39, John Ogness wrote:
> On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> >> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?
> >
> > The people wanting it separate back in the day were those wanting very
> > tiny kernels.  I have not heard from them in a long time, so maybe it
> > is now OK to just make SRCU unconditional.
> 
> Who decides this? Or maybe I should create a semaphore-based Variant of
> console_srcu_read_lock()/console_srcu_read_unlock() for the
> "!CONFIG_PRINTK && !CONFIG_SRCU" case?

I would prefer to avoid it. It would require keeping this in mind.
Semaphore behaves very differently than srcu_read_lock (deadlocks,
nesting).

I am not sure how much the tiny SRCU would increase the size of
the kernel. I doubt that it would be more that what printk()
added by the various per-CPU and per-console buffers.

Well, another question is why we actually need to register the consoles
at all for !CONFIG_PRINTK. Only reasons come to my mind:

   + /dev/console
   + preventing double registration/unregistration (initialization)

I could imagine to handle these two use-cases a special way
on tiny systems. But I would do it only when anyone complains.

Best Regards,
Petr

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Tue, Nov 22, 2022 at 04:33:39PM +0106, John Ogness wrote:
> On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> >> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?
> >
> > The people wanting it separate back in the day were those wanting very
> > tiny kernels.  I have not heard from them in a long time, so maybe it
> > is now OK to just make SRCU unconditional.
> 
> Who decides this? Or maybe I should create a semaphore-based Variant of
> console_srcu_read_lock()/console_srcu_read_unlock() for the
> "!CONFIG_PRINTK && !CONFIG_SRCU" case?

As an alternative, I will queue the patch making SRCU unconditional.  ;-)

							Thanx, Paul

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Tue, Nov 22, 2022 at 04:55:26PM +0100, Petr Mladek wrote:
> On Tue 2022-11-22 16:33:39, John Ogness wrote:
> > On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > >> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?
> > >
> > > The people wanting it separate back in the day were those wanting very
> > > tiny kernels.  I have not heard from them in a long time, so maybe it
> > > is now OK to just make SRCU unconditional.
> > 
> > Who decides this? Or maybe I should create a semaphore-based Variant of
> > console_srcu_read_lock()/console_srcu_read_unlock() for the
> > "!CONFIG_PRINTK && !CONFIG_SRCU" case?
> 
> I would prefer to avoid it. It would require keeping this in mind.
> Semaphore behaves very differently than srcu_read_lock (deadlocks,
> nesting).
> 
> I am not sure how much the tiny SRCU would increase the size of
> the kernel. I doubt that it would be more that what printk()
> added by the various per-CPU and per-console buffers.
> 
> Well, another question is why we actually need to register the consoles
> at all for !CONFIG_PRINTK. Only reasons come to my mind:
> 
>    + /dev/console
>    + preventing double registration/unregistration (initialization)
> 
> I could imagine to handle these two use-cases a special way
> on tiny systems. But I would do it only when anyone complains.

Tiny SRCU is indeed tiny.

And given the large number of "select SRCU" statements out there,
I doubt that there are very many Linux kernels running in production
without SRCU.  Very likely none at all, actually.

I will put together a patch series.

							Thanx, Paul

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Tue, Nov 22, 2022 at 04:55:26PM +0100, Petr Mladek wrote:
> On Tue 2022-11-22 16:33:39, John Ogness wrote:
> > On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > >> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?
> > >
> > > The people wanting it separate back in the day were those wanting very
> > > tiny kernels.  I have not heard from them in a long time, so maybe it
> > > is now OK to just make SRCU unconditional.
> > 
> > Who decides this? Or maybe I should create a semaphore-based Variant of
> > console_srcu_read_lock()/console_srcu_read_unlock() for the
> > "!CONFIG_PRINTK && !CONFIG_SRCU" case?
> 
> I would prefer to avoid it. It would require keeping this in mind.
> Semaphore behaves very differently than srcu_read_lock (deadlocks,
> nesting).
> 
> I am not sure how much the tiny SRCU would increase the size of
> the kernel. I doubt that it would be more that what printk()
> added by the various per-CPU and per-console buffers.
> 
> Well, another question is why we actually need to register the consoles
> at all for !CONFIG_PRINTK. Only reasons come to my mind:
> 
>    + /dev/console
>    + preventing double registration/unregistration (initialization)
> 
> I could imagine to handle these two use-cases a special way
> on tiny systems. But I would do it only when anyone complains.

And here is a first cut.  There will be more patches removing uses
of CONFIG_SRCU.

Thoughts?

							Thanx, Paul

------------------------------------------------------------------------

commit 3721d024963fc35adf92983657dc00edde184d5c
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Tue Nov 22 13:53:57 2022 -0800

    rcu: Make SRCU mandatory
    
    Kernels configured with CONFIG_PRINTK=n and CONFIG_SRCU=n get build
    failures.  This causes trouble for deep embedded systems.  But given
    that there are more than 25 instances of "select SRCU" in the kernel,
    it is hard to believe that there are many kernels running in production
    without SRCU.  This commit therefore makes SRCU mandatory.  The SRCU
    Kconfig option remains for backwards compatibility, and will be removed
    when it is no longer used.
    
    Reported-by: John Ogness <john.ogness@linutronix.de>
    Reported-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index e89d2f7d0f79f..7f17acf29dda7 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -152,11 +152,7 @@ static inline bool rcu_preempt_need_deferred_qs(struct task_struct *t)
 	return false;
 }
 static inline void rcu_preempt_deferred_qs(struct task_struct *t) { }
-#ifdef CONFIG_SRCU
 void rcu_scheduler_starting(void);
-#else /* #ifndef CONFIG_SRCU */
-static inline void rcu_scheduler_starting(void) { }
-#endif /* #else #ifndef CONFIG_SRCU */
 static inline void rcu_end_inkernel_boot(void) { }
 static inline bool rcu_inkernel_boot_has_ended(void) { return true; }
 static inline bool rcu_is_watching(void) { return true; }
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index f0814ffca34bb..7d680ff27505b 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -78,11 +78,7 @@ static inline void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx)
 }
 #endif /* CONFIG_NEED_SRCU_NMI_SAFE */
 
-#ifdef CONFIG_SRCU
 void srcu_init(void);
-#else /* #ifdef CONFIG_SRCU */
-static inline void srcu_init(void) { }
-#endif /* #else #ifdef CONFIG_SRCU */
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 
diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
index 05106e6fbd0ed..ab62074174c32 100644
--- a/kernel/rcu/Kconfig
+++ b/kernel/rcu/Kconfig
@@ -54,21 +54,17 @@ config RCU_EXPERT
 	  Say N if you are unsure.
 
 config SRCU
-	bool
-	help
-	  This option selects the sleepable version of RCU. This version
-	  permits arbitrary sleeping or blocking within RCU read-side critical
-	  sections.
+	def_bool y
 
 config TINY_SRCU
 	bool
-	default y if SRCU && TINY_RCU
+	default y if TINY_RCU
 	help
 	  This option selects the single-CPU non-preemptible version of SRCU.
 
 config TREE_SRCU
 	bool
-	default y if SRCU && !TINY_RCU
+	default y if !TINY_RCU
 	help
 	  This option selects the full-fledged version of SRCU.
 
@@ -77,7 +73,6 @@ config NEED_SRCU_NMI_SAFE
 
 config TASKS_RCU_GENERIC
 	def_bool TASKS_RCU || TASKS_RUDE_RCU || TASKS_TRACE_RCU
-	select SRCU
 	help
 	  This option enables generic infrastructure code supporting
 	  task-based RCU implementations.  Not for manual selection.
diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
index ea654fdae9a06..49da904df6aa6 100644
--- a/kernel/rcu/Kconfig.debug
+++ b/kernel/rcu/Kconfig.debug
@@ -27,7 +27,6 @@ config RCU_SCALE_TEST
 	tristate "performance tests for RCU"
 	depends on DEBUG_KERNEL
 	select TORTURE_TEST
-	select SRCU
 	default n
 	help
 	  This option provides a kernel module that runs performance
@@ -43,7 +42,6 @@ config RCU_TORTURE_TEST
 	tristate "torture tests for RCU"
 	depends on DEBUG_KERNEL
 	select TORTURE_TEST
-	select SRCU
 	default n
 	help
 	  This option provides a kernel module that runs torture tests
@@ -59,7 +57,6 @@ config RCU_REF_SCALE_TEST
 	tristate "Scalability tests for read-side synchronization (RCU and others)"
 	depends on DEBUG_KERNEL
 	select TORTURE_TEST
-	select SRCU
 	default n
 	help
 	  This option provides a kernel module that runs performance tests
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 70c79adfdc704..886e6b0943ab8 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -287,7 +287,7 @@ void rcu_test_sync_prims(void);
  */
 extern void resched_cpu(int cpu);
 
-#if defined(CONFIG_SRCU) || !defined(CONFIG_TINY_RCU)
+#if !defined(CONFIG_TINY_RCU)
 
 #include <linux/rcu_node_tree.h>
 
@@ -438,7 +438,7 @@ do {									\
 #define raw_lockdep_assert_held_rcu_node(p)				\
 	lockdep_assert_held(&ACCESS_PRIVATE(p, lock))
 
-#endif /* #if defined(CONFIG_SRCU) || !defined(CONFIG_TINY_RCU) */
+#endif /* !defined(CONFIG_TINY_RCU) */
 
 #ifdef CONFIG_TINY_RCU
 /* Tiny RCU doesn't expedite, as its purpose in life is instead to be tiny. */
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 76f9848a21cd5..7b1e183b0eb23 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -224,7 +224,7 @@ void rcu_test_sync_prims(void)
 	synchronize_rcu_expedited();
 }
 
-#if !defined(CONFIG_TINY_RCU) || defined(CONFIG_SRCU)
+#if !defined(CONFIG_TINY_RCU)
 
 /*
  * Switch to run-time mode once RCU has fully initialized.
@@ -239,7 +239,7 @@ static int __init rcu_set_runtime_mode(void)
 }
 core_initcall(rcu_set_runtime_mode);
 
-#endif /* #if !defined(CONFIG_TINY_RCU) || defined(CONFIG_SRCU) */
+#endif /* #if !defined(CONFIG_TINY_RCU) */
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 static struct lock_class_key rcu_lock_key;
@@ -561,10 +561,8 @@ static void early_boot_test_call_rcu(void)
 	struct early_boot_kfree_rcu *rhp;
 
 	call_rcu(&head, test_callback);
-	if (IS_ENABLED(CONFIG_SRCU)) {
-		early_srcu_cookie = start_poll_synchronize_srcu(&early_srcu);
-		call_srcu(&early_srcu, &shead, test_callback);
-	}
+	early_srcu_cookie = start_poll_synchronize_srcu(&early_srcu);
+	call_srcu(&early_srcu, &shead, test_callback);
 	rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
 	if (!WARN_ON_ONCE(!rhp))
 		kfree_rcu(rhp, rh);
@@ -587,12 +585,10 @@ static int rcu_verify_early_boot_tests(void)
 	if (rcu_self_test) {
 		early_boot_test_counter++;
 		rcu_barrier();
-		if (IS_ENABLED(CONFIG_SRCU)) {
-			early_boot_test_counter++;
-			srcu_barrier(&early_srcu);
-			WARN_ON_ONCE(!poll_state_synchronize_srcu(&early_srcu, early_srcu_cookie));
-			cleanup_srcu_struct(&early_srcu);
-		}
+		early_boot_test_counter++;
+		srcu_barrier(&early_srcu);
+		WARN_ON_ONCE(!poll_state_synchronize_srcu(&early_srcu, early_srcu_cookie));
+		cleanup_srcu_struct(&early_srcu);
 	}
 	if (rcu_self_test_counter != early_boot_test_counter) {
 		WARN_ON(1);

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Randy Dunlap]

On 11/22/22 14:00, Paul E. McKenney wrote:
> On Tue, Nov 22, 2022 at 04:55:26PM +0100, Petr Mladek wrote:
>> On Tue 2022-11-22 16:33:39, John Ogness wrote:
>>> On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
>>>>> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU?
>>>>
>>>> The people wanting it separate back in the day were those wanting very
>>>> tiny kernels.  I have not heard from them in a long time, so maybe it
>>>> is now OK to just make SRCU unconditional.
>>>
>>> Who decides this? Or maybe I should create a semaphore-based Variant of
>>> console_srcu_read_lock()/console_srcu_read_unlock() for the
>>> "!CONFIG_PRINTK && !CONFIG_SRCU" case?
>>
>> I would prefer to avoid it. It would require keeping this in mind.
>> Semaphore behaves very differently than srcu_read_lock (deadlocks,
>> nesting).
>>
>> I am not sure how much the tiny SRCU would increase the size of
>> the kernel. I doubt that it would be more that what printk()
>> added by the various per-CPU and per-console buffers.
>>
>> Well, another question is why we actually need to register the consoles
>> at all for !CONFIG_PRINTK. Only reasons come to my mind:
>>
>>    + /dev/console
>>    + preventing double registration/unregistration (initialization)
>>
>> I could imagine to handle these two use-cases a special way
>> on tiny systems. But I would do it only when anyone complains.
> 
> And here is a first cut.  There will be more patches removing uses
> of CONFIG_SRCU.
> 
> Thoughts?

UML (x86_64 and i386) was also having this build error.
This patch fixes both of those for me.

Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested

Thanks.

> ------------------------------------------------------------------------
> 
> commit 3721d024963fc35adf92983657dc00edde184d5c
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date:   Tue Nov 22 13:53:57 2022 -0800
> 
>     rcu: Make SRCU mandatory
>     
>     Kernels configured with CONFIG_PRINTK=n and CONFIG_SRCU=n get build
>     failures.  This causes trouble for deep embedded systems.  But given
>     that there are more than 25 instances of "select SRCU" in the kernel,
>     it is hard to believe that there are many kernels running in production
>     without SRCU.  This commit therefore makes SRCU mandatory.  The SRCU
>     Kconfig option remains for backwards compatibility, and will be removed
>     when it is no longer used.
>     
>     Reported-by: John Ogness <john.ogness@linutronix.de>
>     Reported-by: Petr Mladek <pmladek@suse.com>
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index e89d2f7d0f79f..7f17acf29dda7 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -152,11 +152,7 @@ static inline bool rcu_preempt_need_deferred_qs(struct task_struct *t)
>  	return false;
>  }
>  static inline void rcu_preempt_deferred_qs(struct task_struct *t) { }
> -#ifdef CONFIG_SRCU
>  void rcu_scheduler_starting(void);
> -#else /* #ifndef CONFIG_SRCU */
> -static inline void rcu_scheduler_starting(void) { }
> -#endif /* #else #ifndef CONFIG_SRCU */
>  static inline void rcu_end_inkernel_boot(void) { }
>  static inline bool rcu_inkernel_boot_has_ended(void) { return true; }
>  static inline bool rcu_is_watching(void) { return true; }
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index f0814ffca34bb..7d680ff27505b 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -78,11 +78,7 @@ static inline void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx)
>  }
>  #endif /* CONFIG_NEED_SRCU_NMI_SAFE */
>  
> -#ifdef CONFIG_SRCU
>  void srcu_init(void);
> -#else /* #ifdef CONFIG_SRCU */
> -static inline void srcu_init(void) { }
> -#endif /* #else #ifdef CONFIG_SRCU */
>  
>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
>  
> diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
> index 05106e6fbd0ed..ab62074174c32 100644
> --- a/kernel/rcu/Kconfig
> +++ b/kernel/rcu/Kconfig
> @@ -54,21 +54,17 @@ config RCU_EXPERT
>  	  Say N if you are unsure.
>  
>  config SRCU
> -	bool
> -	help
> -	  This option selects the sleepable version of RCU. This version
> -	  permits arbitrary sleeping or blocking within RCU read-side critical
> -	  sections.
> +	def_bool y
>  
>  config TINY_SRCU
>  	bool
> -	default y if SRCU && TINY_RCU
> +	default y if TINY_RCU
>  	help
>  	  This option selects the single-CPU non-preemptible version of SRCU.
>  
>  config TREE_SRCU
>  	bool
> -	default y if SRCU && !TINY_RCU
> +	default y if !TINY_RCU
>  	help
>  	  This option selects the full-fledged version of SRCU.
>  
> @@ -77,7 +73,6 @@ config NEED_SRCU_NMI_SAFE
>  
>  config TASKS_RCU_GENERIC
>  	def_bool TASKS_RCU || TASKS_RUDE_RCU || TASKS_TRACE_RCU
> -	select SRCU
>  	help
>  	  This option enables generic infrastructure code supporting
>  	  task-based RCU implementations.  Not for manual selection.
> diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
> index ea654fdae9a06..49da904df6aa6 100644
> --- a/kernel/rcu/Kconfig.debug
> +++ b/kernel/rcu/Kconfig.debug
> @@ -27,7 +27,6 @@ config RCU_SCALE_TEST
>  	tristate "performance tests for RCU"
>  	depends on DEBUG_KERNEL
>  	select TORTURE_TEST
> -	select SRCU
>  	default n
>  	help
>  	  This option provides a kernel module that runs performance
> @@ -43,7 +42,6 @@ config RCU_TORTURE_TEST
>  	tristate "torture tests for RCU"
>  	depends on DEBUG_KERNEL
>  	select TORTURE_TEST
> -	select SRCU
>  	default n
>  	help
>  	  This option provides a kernel module that runs torture tests
> @@ -59,7 +57,6 @@ config RCU_REF_SCALE_TEST
>  	tristate "Scalability tests for read-side synchronization (RCU and others)"
>  	depends on DEBUG_KERNEL
>  	select TORTURE_TEST
> -	select SRCU
>  	default n
>  	help
>  	  This option provides a kernel module that runs performance tests
> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index 70c79adfdc704..886e6b0943ab8 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -287,7 +287,7 @@ void rcu_test_sync_prims(void);
>   */
>  extern void resched_cpu(int cpu);
>  
> -#if defined(CONFIG_SRCU) || !defined(CONFIG_TINY_RCU)
> +#if !defined(CONFIG_TINY_RCU)
>  
>  #include <linux/rcu_node_tree.h>
>  
> @@ -438,7 +438,7 @@ do {									\
>  #define raw_lockdep_assert_held_rcu_node(p)				\
>  	lockdep_assert_held(&ACCESS_PRIVATE(p, lock))
>  
> -#endif /* #if defined(CONFIG_SRCU) || !defined(CONFIG_TINY_RCU) */
> +#endif /* !defined(CONFIG_TINY_RCU) */
>  
>  #ifdef CONFIG_TINY_RCU
>  /* Tiny RCU doesn't expedite, as its purpose in life is instead to be tiny. */
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 76f9848a21cd5..7b1e183b0eb23 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -224,7 +224,7 @@ void rcu_test_sync_prims(void)
>  	synchronize_rcu_expedited();
>  }
>  
> -#if !defined(CONFIG_TINY_RCU) || defined(CONFIG_SRCU)
> +#if !defined(CONFIG_TINY_RCU)
>  
>  /*
>   * Switch to run-time mode once RCU has fully initialized.
> @@ -239,7 +239,7 @@ static int __init rcu_set_runtime_mode(void)
>  }
>  core_initcall(rcu_set_runtime_mode);
>  
> -#endif /* #if !defined(CONFIG_TINY_RCU) || defined(CONFIG_SRCU) */
> +#endif /* #if !defined(CONFIG_TINY_RCU) */
>  
>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
>  static struct lock_class_key rcu_lock_key;
> @@ -561,10 +561,8 @@ static void early_boot_test_call_rcu(void)
>  	struct early_boot_kfree_rcu *rhp;
>  
>  	call_rcu(&head, test_callback);
> -	if (IS_ENABLED(CONFIG_SRCU)) {
> -		early_srcu_cookie = start_poll_synchronize_srcu(&early_srcu);
> -		call_srcu(&early_srcu, &shead, test_callback);
> -	}
> +	early_srcu_cookie = start_poll_synchronize_srcu(&early_srcu);
> +	call_srcu(&early_srcu, &shead, test_callback);
>  	rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
>  	if (!WARN_ON_ONCE(!rhp))
>  		kfree_rcu(rhp, rh);
> @@ -587,12 +585,10 @@ static int rcu_verify_early_boot_tests(void)
>  	if (rcu_self_test) {
>  		early_boot_test_counter++;
>  		rcu_barrier();
> -		if (IS_ENABLED(CONFIG_SRCU)) {
> -			early_boot_test_counter++;
> -			srcu_barrier(&early_srcu);
> -			WARN_ON_ONCE(!poll_state_synchronize_srcu(&early_srcu, early_srcu_cookie));
> -			cleanup_srcu_struct(&early_srcu);
> -		}
> +		early_boot_test_counter++;
> +		srcu_barrier(&early_srcu);
> +		WARN_ON_ONCE(!poll_state_synchronize_srcu(&early_srcu, early_srcu_cookie));
> +		cleanup_srcu_struct(&early_srcu);
>  	}
>  	if (rcu_self_test_counter != early_boot_test_counter) {
>  		WARN_ON(1);

-- 
~Randy

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[John Ogness]

On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> And here is a first cut.  There will be more patches removing uses
> of CONFIG_SRCU.
>
> Thoughts?

I am happy with it. Thanks!

>     rcu: Make SRCU mandatory
>     
>     Kernels configured with CONFIG_PRINTK=n and CONFIG_SRCU=n get build
>     failures.  This causes trouble for deep embedded systems.  But given
>     that there are more than 25 instances of "select SRCU" in the kernel,
>     it is hard to believe that there are many kernels running in production
>     without SRCU.  This commit therefore makes SRCU mandatory.  The SRCU
>     Kconfig option remains for backwards compatibility, and will be removed
>     when it is no longer used.
>     
>     Reported-by: John Ogness <john.ogness@linutronix.de>
>     Reported-by: Petr Mladek <pmladek@suse.com>
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: John Ogness <john.ogness@linutronix.de>

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Wed, Nov 23, 2022 at 12:20:19AM +0106, John Ogness wrote:
> On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > And here is a first cut.  There will be more patches removing uses
> > of CONFIG_SRCU.
> >
> > Thoughts?
> 
> I am happy with it. Thanks!
> 
> >     rcu: Make SRCU mandatory
> >     
> >     Kernels configured with CONFIG_PRINTK=n and CONFIG_SRCU=n get build
> >     failures.  This causes trouble for deep embedded systems.  But given
> >     that there are more than 25 instances of "select SRCU" in the kernel,
> >     it is hard to believe that there are many kernels running in production
> >     without SRCU.  This commit therefore makes SRCU mandatory.  The SRCU
> >     Kconfig option remains for backwards compatibility, and will be removed
> >     when it is no longer used.
> >     
> >     Reported-by: John Ogness <john.ogness@linutronix.de>
> >     Reported-by: Petr Mladek <pmladek@suse.com>
> >     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Reviewed-by: John Ogness <john.ogness@linutronix.de>

Applied both, and thank you both!

							Thanx, Paul

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Tue, Nov 22, 2022 at 03:42:22PM -0800, Paul E. McKenney wrote:
> On Wed, Nov 23, 2022 at 12:20:19AM +0106, John Ogness wrote:
> > On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > > And here is a first cut.  There will be more patches removing uses
> > > of CONFIG_SRCU.
> > >
> > > Thoughts?
> > 
> > I am happy with it. Thanks!
> > 
> > >     rcu: Make SRCU mandatory
> > >     
> > >     Kernels configured with CONFIG_PRINTK=n and CONFIG_SRCU=n get build
> > >     failures.  This causes trouble for deep embedded systems.  But given
> > >     that there are more than 25 instances of "select SRCU" in the kernel,
> > >     it is hard to believe that there are many kernels running in production
> > >     without SRCU.  This commit therefore makes SRCU mandatory.  The SRCU
> > >     Kconfig option remains for backwards compatibility, and will be removed
> > >     when it is no longer used.
> > >     
> > >     Reported-by: John Ogness <john.ogness@linutronix.de>
> > >     Reported-by: Petr Mladek <pmladek@suse.com>
> > >     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > 
> > Reviewed-by: John Ogness <john.ogness@linutronix.de>
> 
> Applied both, and thank you both!

And this seems have avoided breaking things, so I moved it on top of the
earlier srcunmisafe.2022.11.09a stack with a new srcunmisafe.2022.11.29a
branch name.

If you need me to, I can push this into the upcoming merge window.
Or you could rebase on top of it, so that when the printk() series goes
in, this commit will come along for the ride.

Your choice, just let me know!

							Thanx, Paul

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[John Ogness]

Hi Paul,

On 2022-11-29, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> And this seems have avoided breaking things, so I moved it on top of
> the earlier srcunmisafe.2022.11.09a stack with a new
> srcunmisafe.2022.11.29a branch name.
>
> If you need me to, I can push this into the upcoming merge window.  Or
> you could rebase on top of it, so that when the printk() series goes
> in, this commit will come along for the ride.

It would be great if the series could land in linux-next, to give any
other issues with the series a chance to show up.

Also, since the series is relatively significant, it would probably be
better if it was pushed into the 6.2 merge window by you. Petr will need
to make sure the printk series for the merge window is properly rebased
for it.

Thanks for helping us out here.

John

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Petr Mladek]

On Wed 2022-11-30 09:59:46, John Ogness wrote:
> Hi Paul,
> 
> On 2022-11-29, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > And this seems have avoided breaking things, so I moved it on top of
> > the earlier srcunmisafe.2022.11.09a stack with a new
> > srcunmisafe.2022.11.29a branch name.
> >
> > If you need me to, I can push this into the upcoming merge window.  Or
> > you could rebase on top of it, so that when the printk() series goes
> > in, this commit will come along for the ride.
> 
> It would be great if the series could land in linux-next, to give any
> other issues with the series a chance to show up.
> 
> Also, since the series is relatively significant, it would probably be
> better if it was pushed into the 6.2 merge window by you. Petr will need
> to make sure the printk series for the merge window is properly rebased
> for it.

I have rebased the branch rework/console-list-lock in printk/linux.git
on top of the new srcunmisafe.2022.11.29a.

It means that the changes will be part of the pull request from
the printk tree.

Anyway, it would be nice if Paul adds this branch into the pull request
for RCU tree as well. Then we could both send pull request soon
and it will not matter which one will be handled first.

Does it make any sense, please?

I have never done it this way before. The motivation is to allow
sending both pull requests soon. Linus likes early pull requests.
The fact that it will go also via RCU tree would make it clear
that Paul wanted to send it in this form. Or is it a bad idea?
Do I over-complicate it?

Best Regards,
Petr

Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int]

[Paul E. McKenney]

On Wed, Nov 30, 2022 at 11:37:16AM +0100, Petr Mladek wrote:
> On Wed 2022-11-30 09:59:46, John Ogness wrote:
> > Hi Paul,
> > 
> > On 2022-11-29, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > > And this seems have avoided breaking things, so I moved it on top of
> > > the earlier srcunmisafe.2022.11.09a stack with a new
> > > srcunmisafe.2022.11.29a branch name.
> > >
> > > If you need me to, I can push this into the upcoming merge window.  Or
> > > you could rebase on top of it, so that when the printk() series goes
> > > in, this commit will come along for the ride.
> > 
> > It would be great if the series could land in linux-next, to give any
> > other issues with the series a chance to show up.
> > 
> > Also, since the series is relatively significant, it would probably be
> > better if it was pushed into the 6.2 merge window by you. Petr will need
> > to make sure the printk series for the merge window is properly rebased
> > for it.
> 
> I have rebased the branch rework/console-list-lock in printk/linux.git
> on top of the new srcunmisafe.2022.11.29a.

Very good, thank you!

> It means that the changes will be part of the pull request from
> the printk tree.
> 
> Anyway, it would be nice if Paul adds this branch into the pull request
> for RCU tree as well. Then we could both send pull request soon
> and it will not matter which one will be handled first.
> 
> Does it make any sense, please?
> 
> I have never done it this way before. The motivation is to allow
> sending both pull requests soon. Linus likes early pull requests.
> The fact that it will go also via RCU tree would make it clear
> that Paul wanted to send it in this form. Or is it a bad idea?
> Do I over-complicate it?

All fair points.

I have srcunmisafe.2022.11.29a merged into -rcu immediately following
my RCU merge commit for the upcoming merge window.  My current rcu/next
branch includes it.

So if there are no mandatory-SRCU explosions in -next by Sunday December
4th, I will send Linus this commit in the merge window that is currently
slated to open the week of December 12th:

ec69c6900127 ("srcunmisafe.2022.11.29a: Make SRCU mandatory.")

As the title suggests, this includes the desired commit.

If there are explosions, well, we will deal with them and see where
we go from there.  My fallback commit would be this guy:

87492c06e68d ("Merge branches 'doc.2022.10.20a', 'fixes.2022.10.21a', 'lazy.2022.11.30a', 'srcunmisafe.2022.11.09a', 'torture.2022.10.18c' and 'torturescript.2022.10.20a' into HEAD")

This excludes that commit.  But hopefully there will be no explosions
that cannot be taken care of quickly.

Does that work for you?

							Thanx, Paul