linux-kernel - Re: [PATCH 2/2] Compile error with allmodconfig and CONFIG_PREEMPT_RT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1321334539.6347.43.camel@marge.simson.net>
Date:	Tue, 15 Nov 2011 06:22:19 +0100
From:	Mike Galbraith <efault@....de>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	John Kacur <jkacur@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH 2/2] Compile error with allmodconfig and
 CONFIG_PREEMPT_RT_FULL=y

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@...hat.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/