[PATCH 1/2] v3.2-rc1-52e4c2a05-rt1 fix for compile break

[PATCH 1/2] v3.2-rc1-52e4c2a05-rt1 fix for compile break

[John Kacur]

kernel/rcutorture.c:492: error: ‘synchronize_rcu_bh’ undeclared here (not in a function)

In CONFIG_PREEMPT_RT_FULL
doesn't cover function pointer assignment unless we remove the brackets.

Compile-tested.

Signed-off-by: John Kacur <jkacur@redhat.com>
---
 include/linux/rcutree.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 800b840..6e503a3 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -60,7 +60,7 @@ static inline void exit_rcu(void)
 #ifndef CONFIG_PREEMPT_RT_FULL
 extern void synchronize_rcu_bh(void);
 #else
-# define synchronize_rcu_bh()	synchronize_rcu()
+# define synchronize_rcu_bh	synchronize_rcu
 #endif
 extern void synchronize_sched_expedited(void);
 extern void synchronize_rcu_expedited(void);
-- 
1.7.2.3

[PATCH 1/2] v3.2-rc1-52e4c2a05-rt1 fix for compile break

[John Kacur]

kernel/rcutorture.c:492: error: ‘synchronize_rcu_bh’ undeclared here (not in a function)

In CONFIG_PREEMPT_RT_FULL
doesn't cover function pointer assignment unless we remove the brackets.

Compile-tested.

Signed-off-by: John Kacur <jkacur@redhat.com>
---
 include/linux/rcutree.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 800b840..6e503a3 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -60,7 +60,7 @@ static inline void exit_rcu(void)
 #ifndef CONFIG_PREEMPT_RT_FULL
 extern void synchronize_rcu_bh(void);
 #else
-# define synchronize_rcu_bh()	synchronize_rcu()
+# define synchronize_rcu_bh	synchronize_rcu
 #endif
 extern void synchronize_sched_expedited(void);
 extern void synchronize_rcu_expedited(void);
-- 
1.7.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[John Kacur]

ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!

The above can be fixed by exporting in_serving_softirq

Signed-off-by: John Kacur <jkacur@redhat.com>

The above patch was originally for 3.0.9-rt25
But I also needed to cherry-pick it for 3.2-rc1-rt1
---
 kernel/softirq.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 3db1d6f..5452432 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -447,6 +447,7 @@ int in_serving_softirq(void)
 	preempt_enable();
 	return res;
 }
+EXPORT_SYMBOL(in_serving_softirq);
 
 /*
  * Called with bh and local interrupts disabled. For full RT cpu must
-- 
1.7.2.3

Re: [PATCH 1/2] v3.2-rc1-52e4c2a05-rt1 fix for compile break

[Paul E. McKenney]

On Mon, Nov 14, 2011 at 02:44:42AM +0100, John Kacur wrote:
> kernel/rcutorture.c:492: error: ‘synchronize_rcu_bh’ undeclared here (not in a function)
> 
> In CONFIG_PREEMPT_RT_FULL
> doesn't cover function pointer assignment unless we remove the brackets.
> 
> Compile-tested.

Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

I have not yet queued this because mainline does not yet fold RCU and
RCU-bh together.

							Thanx, Paul

> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
>  include/linux/rcutree.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
> index 800b840..6e503a3 100644
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -60,7 +60,7 @@ static inline void exit_rcu(void)
>  #ifndef CONFIG_PREEMPT_RT_FULL
>  extern void synchronize_rcu_bh(void);
>  #else
> -# define synchronize_rcu_bh()	synchronize_rcu()
> +# define synchronize_rcu_bh	synchronize_rcu
>  #endif
>  extern void synchronize_sched_expedited(void);
>  extern void synchronize_rcu_expedited(void);
> -- 
> 1.7.2.3
> 

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Paul E. McKenney]

On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> 
> The above can be fixed by exporting in_serving_softirq
> 
> Signed-off-by: John Kacur <jkacur@redhat.com>
> 
> The above patch was originally for 3.0.9-rt25
> But I also needed to cherry-pick it for 3.2-rc1-rt1
> ---
>  kernel/softirq.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 3db1d6f..5452432 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -447,6 +447,7 @@ int in_serving_softirq(void)
>  	preempt_enable();
>  	return res;
>  }
> +EXPORT_SYMBOL(in_serving_softirq);

Why not EXPORT_SYMBOL_GPL?

With that change,

Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Not yet ready for mainline, because mainline does not yet have
in_serving_softirq().  Therefore not queued for -rcu.

							Thanx, Paul

>  /*
>   * Called with bh and local interrupts disabled. For full RT cpu must
> -- 
> 1.7.2.3
> 

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[John Kacur]

On Mon, 14 Nov 2011, Paul E. McKenney wrote:

> On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> > ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> > 
> > The above can be fixed by exporting in_serving_softirq
> > 
> > Signed-off-by: John Kacur <jkacur@redhat.com>
> > 
> > The above patch was originally for 3.0.9-rt25
> > But I also needed to cherry-pick it for 3.2-rc1-rt1
> > ---
> >  kernel/softirq.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > index 3db1d6f..5452432 100644
> > --- a/kernel/softirq.c
> > +++ b/kernel/softirq.c
> > @@ -447,6 +447,7 @@ int in_serving_softirq(void)
> >  	preempt_enable();
> >  	return res;
> >  }
> > +EXPORT_SYMBOL(in_serving_softirq);
> 
> Why not EXPORT_SYMBOL_GPL?

I have no problem with that, note however that the upstream file has

EXPORT_SYMBOL(irq_stat);
EXPORT_SYMBOL(local_bh_disable);
EXPORT_SYMBOL(_local_bh_enable);
EXPORT_SYMBOL(local_bh_enable);
EXPORT_SYMBOL(local_bh_enable_ip);
EXPORT_SYMBOL(__tasklet_schedule);
EXPORT_SYMBOL(__tasklet_hi_schedule);
EXPORT_SYMBOL(__tasklet_hi_schedule_first);
EXPORT_SYMBOL(tasklet_init);
EXPORT_SYMBOL(tasklet_kill);
EXPORT_SYMBOL(__send_remote_softirq);
EXPORT_SYMBOL(send_remote_softirq);

Any reason we can't change all of those to EXPORT_SYMBOL_GPL?

> 
> With that change,
> 
> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> Not yet ready for mainline, because mainline does not yet have
> in_serving_softirq().  Therefore not queued for -rcu.
> 
> 							Thanx, Paul
> 
> >  /*
> >   * Called with bh and local interrupts disabled. For full RT cpu must

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Paul E. McKenney]

On Mon, Nov 14, 2011 at 06:39:47PM +0100, John Kacur wrote:
> 
> 
> On Mon, 14 Nov 2011, Paul E. McKenney wrote:
> 
> > On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> > > ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> > > 
> > > The above can be fixed by exporting in_serving_softirq
> > > 
> > > Signed-off-by: John Kacur <jkacur@redhat.com>
> > > 
> > > The above patch was originally for 3.0.9-rt25
> > > But I also needed to cherry-pick it for 3.2-rc1-rt1
> > > ---
> > >  kernel/softirq.c |    1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > index 3db1d6f..5452432 100644
> > > --- a/kernel/softirq.c
> > > +++ b/kernel/softirq.c
> > > @@ -447,6 +447,7 @@ int in_serving_softirq(void)
> > >  	preempt_enable();
> > >  	return res;
> > >  }
> > > +EXPORT_SYMBOL(in_serving_softirq);
> > 
> > Why not EXPORT_SYMBOL_GPL?
> 
> I have no problem with that, note however that the upstream file has
> 
> EXPORT_SYMBOL(irq_stat);
> EXPORT_SYMBOL(local_bh_disable);
> EXPORT_SYMBOL(_local_bh_enable);
> EXPORT_SYMBOL(local_bh_enable);
> EXPORT_SYMBOL(local_bh_enable_ip);
> EXPORT_SYMBOL(__tasklet_schedule);
> EXPORT_SYMBOL(__tasklet_hi_schedule);
> EXPORT_SYMBOL(__tasklet_hi_schedule_first);
> EXPORT_SYMBOL(tasklet_init);
> EXPORT_SYMBOL(tasklet_kill);
> EXPORT_SYMBOL(__send_remote_softirq);
> EXPORT_SYMBOL(send_remote_softirq);
> 
> Any reason we can't change all of those to EXPORT_SYMBOL_GPL?

No idea.  But I do suggest making new ones EXPORT_SYMBOL_GPL.

							Thanx, Paul

> > With that change,
> > 
> > Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > Not yet ready for mainline, because mainline does not yet have
> > in_serving_softirq().  Therefore not queued for -rcu.
> > 
> > 							Thanx, Paul
> > 
> > >  /*
> > >   * Called with bh and local interrupts disabled. For full RT cpu must
> 

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Steven Rostedt]

On Mon, 2011-11-14 at 18:39 +0100, John Kacur wrote:
> 
> On Mon, 14 Nov 2011, Paul E. McKenney wrote:
> 
> > On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> > > ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> > > 
> > > The above can be fixed by exporting in_serving_softirq
> > > 
> > > Signed-off-by: John Kacur <jkacur@redhat.com>
> > > 
> > > The above patch was originally for 3.0.9-rt25
> > > But I also needed to cherry-pick it for 3.2-rc1-rt1
> > > ---
> > >  kernel/softirq.c |    1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > index 3db1d6f..5452432 100644
> > > --- a/kernel/softirq.c
> > > +++ b/kernel/softirq.c
> > > @@ -447,6 +447,7 @@ int in_serving_softirq(void)
> > >  	preempt_enable();
> > >  	return res;
> > >  }
> > > +EXPORT_SYMBOL(in_serving_softirq);
> > 
> > Why not EXPORT_SYMBOL_GPL?
> 
> I have no problem with that, note however that the upstream file has
> 
> EXPORT_SYMBOL(irq_stat);
> EXPORT_SYMBOL(local_bh_disable);
> EXPORT_SYMBOL(_local_bh_enable);
> EXPORT_SYMBOL(local_bh_enable);
> EXPORT_SYMBOL(local_bh_enable_ip);
> EXPORT_SYMBOL(__tasklet_schedule);
> EXPORT_SYMBOL(__tasklet_hi_schedule);
> EXPORT_SYMBOL(__tasklet_hi_schedule_first);
> EXPORT_SYMBOL(tasklet_init);
> EXPORT_SYMBOL(tasklet_kill);
> EXPORT_SYMBOL(__send_remote_softirq);
> EXPORT_SYMBOL(send_remote_softirq);
> 
> Any reason we can't change all of those to EXPORT_SYMBOL_GPL?\\

IIRC, the point behind EXPORT_SYMBOL_GPL() is that, by using the call
you are using something that is a derivative of the code. Basically all
new functionality of the kernel is Linux specific and symbols exported
should be EXPORT_SYMBOL_GPL().

But, I also recall that we did not want to make things that are normal
OS operations under the EXPORT_SYMBOL_GPL(). This would include the
local_bh_enable/disable(), or anything that is called by generic
operations. For example, spin_lock() is not a GPL symbol, and if we add
some new functionality that causes all spin_locks() to call foo_bar(),
we must also make sure foo_bar() is also under just EXPORT_SYMBOL(),
otherwise, we just forced EXPORT_SYMBOL_GPL() on spin_lock().

Some of the above is probably just simple OS operations or are called by
static OS operation functions.

If we go that route, we might as well make everything
EXPORT_SYMBOL_GPL(), and be damn to those that use nVidia.

-- Steve

Re: [PATCH 1/2] v3.2-rc1-52e4c2a05-rt1 fix for compile break

[Steven Rostedt]

On Mon, 2011-11-14 at 02:44 +0100, John Kacur wrote:
> kernel/rcutorture.c:492: error: ‘synchronize_rcu_bh’ undeclared here (not in a function)
> 
> In CONFIG_PREEMPT_RT_FULL
> doesn't cover function pointer assignment unless we remove the brackets.

John,

Please write better change logs. Do not assume that people are looking
at the patch while looking at the logs. I mostly read change logs as
"git log" which doesn't include the changes, and most other developers
do this too. The above sentence does not make any real sense.

Something like:

synchronize_rcu_bh() is not just called as a normal function, but can
also be referenced as a function pointer. When CONFIG_PREEMPT_RT_FULL is
enabled, synchronize_rcu_bh() is defined as synchronize_rcu(), but needs
to be defined without the parenthesis because the compiler will complain
when synchronize_rcu_bh is referenced as a function pointer and not a
function.

-- Steve



> 
> Compile-tested.
> 
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
>  include/linux/rcutree.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
> index 800b840..6e503a3 100644
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -60,7 +60,7 @@ static inline void exit_rcu(void)
>  #ifndef CONFIG_PREEMPT_RT_FULL
>  extern void synchronize_rcu_bh(void);
>  #else
> -# define synchronize_rcu_bh()	synchronize_rcu()
> +# define synchronize_rcu_bh	synchronize_rcu
>  #endif
>  extern void synchronize_sched_expedited(void);
>  extern void synchronize_rcu_expedited(void);

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[John Kacur]

On Mon, Nov 14, 2011 at 9:51 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 2011-11-14 at 18:39 +0100, John Kacur wrote:
> >
> > On Mon, 14 Nov 2011, Paul E. McKenney wrote:
> >
> > > On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> > > > ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> > > >
> > > > The above can be fixed by exporting in_serving_softirq
> > > >
> > > > Signed-off-by: John Kacur <jkacur@redhat.com>
> > > >
> > > > The above patch was originally for 3.0.9-rt25
> > > > But I also needed to cherry-pick it for 3.2-rc1-rt1
> > > > ---
> > > >  kernel/softirq.c |    1 +
> > > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > > index 3db1d6f..5452432 100644
> > > > --- a/kernel/softirq.c
> > > > +++ b/kernel/softirq.c
> > > > @@ -447,6 +447,7 @@ int in_serving_softirq(void)
> > > >   preempt_enable();
> > > >   return res;
> > > >  }
> > > > +EXPORT_SYMBOL(in_serving_softirq);
> > >
> > > Why not EXPORT_SYMBOL_GPL?
> >
> > I have no problem with that, note however that the upstream file has
> >
> > EXPORT_SYMBOL(irq_stat);
> > EXPORT_SYMBOL(local_bh_disable);
> > EXPORT_SYMBOL(_local_bh_enable);
> > EXPORT_SYMBOL(local_bh_enable);
> > EXPORT_SYMBOL(local_bh_enable_ip);
> > EXPORT_SYMBOL(__tasklet_schedule);
> > EXPORT_SYMBOL(__tasklet_hi_schedule);
> > EXPORT_SYMBOL(__tasklet_hi_schedule_first);
> > EXPORT_SYMBOL(tasklet_init);
> > EXPORT_SYMBOL(tasklet_kill);
> > EXPORT_SYMBOL(__send_remote_softirq);
> > EXPORT_SYMBOL(send_remote_softirq);
> >
> > Any reason we can't change all of those to EXPORT_SYMBOL_GPL?\\
>
> IIRC, the point behind EXPORT_SYMBOL_GPL() is that, by using the call
> you are using something that is a derivative of the code. Basically all
> new functionality of the kernel is Linux specific and symbols exported
> should be EXPORT_SYMBOL_GPL().
>
> But, I also recall that we did not want to make things that are normal
> OS operations under the EXPORT_SYMBOL_GPL(). This would include the
> local_bh_enable/disable(), or anything that is called by generic
> operations. For example, spin_lock() is not a GPL symbol, and if we add
> some new functionality that causes all spin_locks() to call foo_bar(),
> we must also make sure foo_bar() is also under just EXPORT_SYMBOL(),
> otherwise, we just forced EXPORT_SYMBOL_GPL() on spin_lock().
>
> Some of the above is probably just simple OS operations or are called by
> static OS operation functions.
>
> If we go that route, we might as well make everything
> EXPORT_SYMBOL_GPL(), and be damn to those that use nVidia.
>
> -- Steve


That's a great explanation - thanks

John Kacur

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[John Kacur]

On Mon, Nov 14, 2011 at 9:51 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 2011-11-14 at 18:39 +0100, John Kacur wrote:
> >
> > On Mon, 14 Nov 2011, Paul E. McKenney wrote:
> >
> > > On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> > > > ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> > > >
> > > > The above can be fixed by exporting in_serving_softirq
> > > >
> > > > Signed-off-by: John Kacur <jkacur@redhat.com>
> > > >
> > > > The above patch was originally for 3.0.9-rt25
> > > > But I also needed to cherry-pick it for 3.2-rc1-rt1
> > > > ---
> > > >  kernel/softirq.c |    1 +
> > > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > > index 3db1d6f..5452432 100644
> > > > --- a/kernel/softirq.c
> > > > +++ b/kernel/softirq.c
> > > > @@ -447,6 +447,7 @@ int in_serving_softirq(void)
> > > >   preempt_enable();
> > > >   return res;
> > > >  }
> > > > +EXPORT_SYMBOL(in_serving_softirq);
> > >
> > > Why not EXPORT_SYMBOL_GPL?
> >
> > I have no problem with that, note however that the upstream file has
> >
> > EXPORT_SYMBOL(irq_stat);
> > EXPORT_SYMBOL(local_bh_disable);
> > EXPORT_SYMBOL(_local_bh_enable);
> > EXPORT_SYMBOL(local_bh_enable);
> > EXPORT_SYMBOL(local_bh_enable_ip);
> > EXPORT_SYMBOL(__tasklet_schedule);
> > EXPORT_SYMBOL(__tasklet_hi_schedule);
> > EXPORT_SYMBOL(__tasklet_hi_schedule_first);
> > EXPORT_SYMBOL(tasklet_init);
> > EXPORT_SYMBOL(tasklet_kill);
> > EXPORT_SYMBOL(__send_remote_softirq);
> > EXPORT_SYMBOL(send_remote_softirq);
> >
> > Any reason we can't change all of those to EXPORT_SYMBOL_GPL?\\
>
> IIRC, the point behind EXPORT_SYMBOL_GPL() is that, by using the call
> you are using something that is a derivative of the code. Basically all
> new functionality of the kernel is Linux specific and symbols exported
> should be EXPORT_SYMBOL_GPL().
>
> But, I also recall that we did not want to make things that are normal
> OS operations under the EXPORT_SYMBOL_GPL(). This would include the
> local_bh_enable/disable(), or anything that is called by generic
> operations. For example, spin_lock() is not a GPL symbol, and if we add
> some new functionality that causes all spin_locks() to call foo_bar(),
> we must also make sure foo_bar() is also under just EXPORT_SYMBOL(),
> otherwise, we just forced EXPORT_SYMBOL_GPL() on spin_lock().
>
> Some of the above is probably just simple OS operations or are called by
> static OS operation functions.
>
> If we go that route, we might as well make everything
> EXPORT_SYMBOL_GPL(), and be damn to those that use nVidia.
>
> -- Steve


That's a great explanation - thanks

John Kacur
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Mike Galbraith]

On Mon, 2011-11-14 at 15:51 -0500, Steven Rostedt wrote:
> On Mon, 2011-11-14 at 18:39 +0100, John Kacur wrote:
> > 
> > On Mon, 14 Nov 2011, Paul E. McKenney wrote:
> > 
> > > On Mon, Nov 14, 2011 at 02:44:43AM +0100, John Kacur wrote:
> > > > ERROR: "in_serving_softirq" [net/sched/cls_cgroup.ko] undefined!
> > > > 
> > > > The above can be fixed by exporting in_serving_softirq
> > > > 
> > > > Signed-off-by: John Kacur <jkacur@redhat.com>
> > > > 
> > > > The above patch was originally for 3.0.9-rt25
> > > > But I also needed to cherry-pick it for 3.2-rc1-rt1
> > > > ---
> > > >  kernel/softirq.c |    1 +
> > > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > > index 3db1d6f..5452432 100644
> > > > --- a/kernel/softirq.c
> > > > +++ b/kernel/softirq.c
> > > > @@ -447,6 +447,7 @@ int in_serving_softirq(void)
> > > >  	preempt_enable();
> > > >  	return res;
> > > >  }
> > > > +EXPORT_SYMBOL(in_serving_softirq);
> > > 
> > > Why not EXPORT_SYMBOL_GPL?
> > 
> > I have no problem with that, note however that the upstream file has
> > 
> > EXPORT_SYMBOL(irq_stat);
> > EXPORT_SYMBOL(local_bh_disable);
> > EXPORT_SYMBOL(_local_bh_enable);
> > EXPORT_SYMBOL(local_bh_enable);
> > EXPORT_SYMBOL(local_bh_enable_ip);
> > EXPORT_SYMBOL(__tasklet_schedule);
> > EXPORT_SYMBOL(__tasklet_hi_schedule);
> > EXPORT_SYMBOL(__tasklet_hi_schedule_first);
> > EXPORT_SYMBOL(tasklet_init);
> > EXPORT_SYMBOL(tasklet_kill);
> > EXPORT_SYMBOL(__send_remote_softirq);
> > EXPORT_SYMBOL(send_remote_softirq);
> > 
> > Any reason we can't change all of those to EXPORT_SYMBOL_GPL?\\
> 
> IIRC, the point behind EXPORT_SYMBOL_GPL() is that, by using the call
> you are using something that is a derivative of the code. Basically all
> new functionality of the kernel is Linux specific and symbols exported
> should be EXPORT_SYMBOL_GPL().
> 
> But, I also recall that we did not want to make things that are normal
> OS operations under the EXPORT_SYMBOL_GPL(). This would include the
> local_bh_enable/disable(), or anything that is called by generic
> operations. For example, spin_lock() is not a GPL symbol, and if we add
> some new functionality that causes all spin_locks() to call foo_bar(),
> we must also make sure foo_bar() is also under just EXPORT_SYMBOL(),
> otherwise, we just forced EXPORT_SYMBOL_GPL() on spin_lock().
> 
> Some of the above is probably just simple OS operations or are called by
> static OS operation functions.
> 
> If we go that route, we might as well make everything
> EXPORT_SYMBOL_GPL(), and be damn to those that use nVidia.

EXPORT_SYMBOL_GPL(migrate_disable) alone screws nVidia users, no?

I have an RT user who has no other viable choice than nVidia.  If the
above is true, that user will end up stuck at 2.6.33-rt until we get a
driver that actually works... or they deem linux to be a non-solution.

	-Mike

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Steven Rostedt]

On Tue, 2011-11-15 at 06:22 +0100, Mike Galbraith wrote:

> > If we go that route, we might as well make everything
> > EXPORT_SYMBOL_GPL(), and be damn to those that use nVidia.
> 
> EXPORT_SYMBOL_GPL(migrate_disable) alone screws nVidia users, no?
> 
> I have an RT user who has no other viable choice than nVidia.  If the
> above is true, that user will end up stuck at 2.6.33-rt until we get a
> driver that actually works... or they deem linux to be a non-solution.

Right, migrate_disable() should not have been an EXPORT_SYMBOL_GPL(), as
it is a helper functions that is also exported as EXPORT_SYMBOL(). It
shouldn't be called directly anyway, even by code in the kernel proper.

-- Steve

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Mike Galbraith]

On Tue, 2011-11-15 at 07:23 -0500, Steven Rostedt wrote:

> Right, migrate_disable() should not have been an EXPORT_SYMBOL_GPL(), as
> it is a helper functions that is also exported as EXPORT_SYMBOL(). It
> shouldn't be called directly anyway, even by code in the kernel proper.

Ah.  Doesn't matter though.  I downloaded their latest, tried to build
it with EXPORT_SYMBOL(migrate_enable/disable) ..

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rt_mutex_init'

With that exported, the thing builds and runs, but rt_mutex_foo exports
appear to be intentionally GPL only, so it's "go fish" for nVidia.

	-Mike

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Mike Galbraith]

On Tue, 2011-11-15 at 14:27 +0100, Mike Galbraith wrote:

> With that exported, the thing builds and runs, but rt_mutex_foo exports
> appear to be intentionally GPL only, so it's "go fish" for nVidia.

BTW, if you poke that nVidia beast right, it'll keep you locked in
kernel IPI-ing every CPU as fast as we can do that for up to a full
second :>  The only thing I ever found that can match that is ext4.

	-Mike

Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT_FULL=y

[Mike Galbraith]

On Tue, 2011-11-15 at 14:27 +0100, Mike Galbraith wrote:
> On Tue, 2011-11-15 at 07:23 -0500, Steven Rostedt wrote:
> 
> > Right, migrate_disable() should not have been an EXPORT_SYMBOL_GPL(), as
> > it is a helper functions that is also exported as EXPORT_SYMBOL(). It
> > shouldn't be called directly anyway, even by code in the kernel proper.
> 
> Ah.  Doesn't matter though.  I downloaded their latest, tried to build
> it with EXPORT_SYMBOL(migrate_enable/disable) ..
> 
> FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rt_mutex_init'
> 
> With that exported, the thing builds and runs, but rt_mutex_foo exports
> appear to be intentionally GPL only, so it's "go fish" for nVidia.

Bah.  I checked the crusty old hack for crusty old driver, and it still
works just fine with a trivial define.  It'd probably work better if it
didn't need cheezy raw_* hacks, but then it'd probably work better if it
was GPL too ;-)

	-Mike

SUSE question wrt RT locking primitives

[Mike Galbraith]

Greetings,

SUSE is looking for a straight up answer, I've been tasked with asking
the question: can RT maintainers be convinced to fix the RT tree such
that locking primitives do not switch from 'OK' to TABOO' at the flick
of a config switch?  It is understood that "yes" may have undesirable
side-effects :)

Background:

The migrate_enable/disable() EXPORT_SYMBOL_GPL thing came up yesterday
again with yet another customer stuck using yet another proprietary
driver for proprietary hardware.  The choice for the customer/user is
use what exists, knock on proprietary doors, or go look at platforms
where the proprietary gizmo they need or want to use just works.

So that's where the question comes from.  Life would be easier if RT
didn't trigger the Dr. Jeckle -> Mr. Hyde thing.  You know all about
where what happens to which locks, so I'll just snip what I had quoted
and needlessly commented on to keep this as short as possible ;-)

-Mike

Re: SUSE question wrt RT locking primitives

[Steven Rostedt]

On Fri, 2012-04-13 at 07:34 +0200, Mike Galbraith wrote:
> Greetings,
> 
> SUSE is looking for a straight up answer, I've been tasked with asking
> the question: can RT maintainers be convinced to fix the RT tree such
> that locking primitives do not switch from 'OK' to TABOO' at the flick
> of a config switch?  It is understood that "yes" may have undesirable
> side-effects :)
> 
> Background:
> 
> The migrate_enable/disable() EXPORT_SYMBOL_GPL thing came up yesterday
> again with yet another customer stuck using yet another proprietary
> driver for proprietary hardware.  The choice for the customer/user is
> use what exists, knock on proprietary doors, or go look at platforms
> where the proprietary gizmo they need or want to use just works.
> 
> So that's where the question comes from.  Life would be easier if RT
> didn't trigger the Dr. Jeckle -> Mr. Hyde thing.  You know all about
> where what happens to which locks, so I'll just snip what I had quoted
> and needlessly commented on to keep this as short as possible ;-)

I have no problem with making those non-GPL, as the original stance of
-rt back in 2005 was to not have -rt be any different than the vanilla
kernel in that regards. But I don't know if that policy changed since
then, nor am I the one that has the authority to remove the GPL tags
from those functions.

-- Steve

Re: SUSE question wrt RT locking primitives

[Mike Galbraith]

On Fri, 2012-04-13 at 08:58 -0400, Steven Rostedt wrote: 
> On Fri, 2012-04-13 at 07:34 +0200, Mike Galbraith wrote:

> > So that's where the question comes from.  Life would be easier if RT
> > didn't trigger the Dr. Jeckle -> Mr. Hyde thing.  You know all about
> > where what happens to which locks, so I'll just snip what I had quoted
> > and needlessly commented on to keep this as short as possible ;-)
> 
> I have no problem with making those non-GPL, as the original stance of
> -rt back in 2005 was to not have -rt be any different than the vanilla
> kernel in that regards. But I don't know if that policy changed since
> then, nor am I the one that has the authority to remove the GPL tags
> from those functions.

As timing would have it, Thomas changed to ones that the nVidia driver
griped about before I even got the query sent.  I just built and ran it,
it's happy in unmolested form.  Dunno if this will make all RT module
grumbles go away, but the nVidia ones should be toast.

-Mike

Re: SUSE question wrt RT locking primitives

[Thomas Gleixner]

On Fri, 13 Apr 2012, Mike Galbraith wrote:

> On Fri, 2012-04-13 at 08:58 -0400, Steven Rostedt wrote: 
> > On Fri, 2012-04-13 at 07:34 +0200, Mike Galbraith wrote:
> 
> > > So that's where the question comes from.  Life would be easier if RT
> > > didn't trigger the Dr. Jeckle -> Mr. Hyde thing.  You know all about
> > > where what happens to which locks, so I'll just snip what I had quoted
> > > and needlessly commented on to keep this as short as possible ;-)
> > 
> > I have no problem with making those non-GPL, as the original stance of
> > -rt back in 2005 was to not have -rt be any different than the vanilla
> > kernel in that regards. But I don't know if that policy changed since
> > then, nor am I the one that has the authority to remove the GPL tags
> > from those functions.
> 
> As timing would have it, Thomas changed to ones that the nVidia driver
> griped about before I even got the query sent.  I just built and ran it,
> it's happy in unmolested form.  Dunno if this will make all RT module
> grumbles go away, but the nVidia ones should be toast.

AFAICT, that should solve all of the RT induced problems.

Feel free to forward my announce mail to those who made you write that
request :)

Thanks,

	tglx