CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know there's not much sympathy for troubles with proprietary modules
here, but the following might save some trouble to kernel developers as
well as users forced to resort to proprietary drivers:

Setting the kernel configuration option PROVE_RCU creates a reference to
the GPL-exported global variable rcu_lock_map even in modules that do
not use RCU. In the case of non-GPL modules, this leads to a build
failure because of the license incompatibility.
(I did not find out where that reference comes from.)

So if building a proprietary module fails with the message:

FATAL: modpost: GPL-incompatible module <module> uses GPL-only symbol
'rcu_lock_map'

try rebuilding your kernel with the PROVE_RCU option disabled.

Hope it helps someone.

Tilman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkumieoACgkQQ3+did9BuFtC4gCggSE8DNVc8k9tasN7VOoQMR4G
IKUAnj+SkzZjmJQPmUScvaY4zP8hR19o
=2rDg
-----END PGP SIGNATURE-----

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Paul E. McKenney]

On Sun, Mar 21, 2010 at 10:04:42PM +0100, Tilman Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I know there's not much sympathy for troubles with proprietary modules
> here, but the following might save some trouble to kernel developers as
> well as users forced to resort to proprietary drivers:
> 
> Setting the kernel configuration option PROVE_RCU creates a reference to
> the GPL-exported global variable rcu_lock_map even in modules that do
> not use RCU. In the case of non-GPL modules, this leads to a build
> failure because of the license incompatibility.
> (I did not find out where that reference comes from.)
> 
> So if building a proprietary module fails with the message:
> 
> FATAL: modpost: GPL-incompatible module <module> uses GPL-only symbol
> 'rcu_lock_map'
> 
> try rebuilding your kernel with the PROVE_RCU option disabled.
> 
> Hope it helps someone.

I am comfortable with PROVE_RCU being incompatible with non-GPL modules.
After all, it is only a debugging option, not intended for production use.

							Thanx, Paul

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Am 29.03.2010 17:09 schrieb Paul E. McKenney:
> On Sun, Mar 21, 2010 at 10:04:42PM +0100, Tilman Schmidt wrote:
[...]
>> So if building a proprietary module fails with the message:
>>
>> FATAL: modpost: GPL-incompatible module <module> uses GPL-only symbol
>> 'rcu_lock_map'
>>
>> try rebuilding your kernel with the PROVE_RCU option disabled.
>>
>> Hope it helps someone.
> 
> I am comfortable with PROVE_RCU being incompatible with non-GPL modules.
> After all, it is only a debugging option, not intended for production use.

I agree completely. I just wanted to publish that fact because it seems
to be little known and can be quite a puzzler.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Paul E. McKenney]

On Mon, Mar 29, 2010 at 07:53:59PM +0200, Tilman Schmidt wrote:
> Am 29.03.2010 17:09 schrieb Paul E. McKenney:
> > On Sun, Mar 21, 2010 at 10:04:42PM +0100, Tilman Schmidt wrote:
> [...]
> >> So if building a proprietary module fails with the message:
> >>
> >> FATAL: modpost: GPL-incompatible module <module> uses GPL-only symbol
> >> 'rcu_lock_map'
> >>
> >> try rebuilding your kernel with the PROVE_RCU option disabled.
> >>
> >> Hope it helps someone.
> > 
> > I am comfortable with PROVE_RCU being incompatible with non-GPL modules.
> > After all, it is only a debugging option, not intended for production use.
> 
> I agree completely. I just wanted to publish that fact because it seems
> to be little known and can be quite a puzzler.

And I do very much appreciate your publicizing the solution!  ;-)

						Thanx, Paul

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Kyle McMartin]

On Mon, Mar 29, 2010 at 11:40:59AM -0700, Paul E. McKenney wrote:
> > > I am comfortable with PROVE_RCU being incompatible with non-GPL modules.
> > > After all, it is only a debugging option, not intended for production use.
> > 
> > I agree completely. I just wanted to publish that fact because it seems
> > to be little known and can be quite a puzzler.
> 
> And I do very much appreciate your publicizing the solution!  ;-)
> 

Hi Paul,

(Sorry I didn't bring this up until now.)

I don't really have any sympathy for people who use that crud, but from
my POV it's going to generate some grief. Fedora builds rawhide with a
lot of debugging options enabled in order to try and hit issues early
before kernels release.

A few weeks ago, I noticed a report that PROVE_RCU was breaking some
non-GPL junk. Digging a bit further, I noticed quite a number of more
reports of this.

Is there any chances you could reconsider this? Otherwise I'll probably
disable the option in Fedora's debug kernels as well if I continue to
see confused users.

--Kyle

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Paul E. McKenney]

On Thu, Jun 17, 2010 at 06:37:47AM -0400, Kyle McMartin wrote:
> On Mon, Mar 29, 2010 at 11:40:59AM -0700, Paul E. McKenney wrote:
> > > > I am comfortable with PROVE_RCU being incompatible with non-GPL modules.
> > > > After all, it is only a debugging option, not intended for production use.
> > > 
> > > I agree completely. I just wanted to publish that fact because it seems
> > > to be little known and can be quite a puzzler.
> > 
> > And I do very much appreciate your publicizing the solution!  ;-)
> > 
> 
> Hi Paul,
> 
> (Sorry I didn't bring this up until now.)
> 
> I don't really have any sympathy for people who use that crud, but from
> my POV it's going to generate some grief. Fedora builds rawhide with a
> lot of debugging options enabled in order to try and hit issues early
> before kernels release.
> 
> A few weeks ago, I noticed a report that PROVE_RCU was breaking some
> non-GPL junk. Digging a bit further, I noticed quite a number of more
> reports of this.
> 
> Is there any chances you could reconsider this? Otherwise I'll probably
> disable the option in Fedora's debug kernels as well if I continue to
> see confused users.

Hello, Kyle,

My kneejerk reaction is that PROVE_RCU is a developer tool, so I am
OK with it not being set by default in Rawhide.  Or have you seen good
value from (say) PROVE_LOCKING in Rawhide?

							Thanx, Paul

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Kyle McMartin]

On Sun, Jun 20, 2010 at 08:16:05AM -0700, Paul E. McKenney wrote:
> My kneejerk reaction is that PROVE_RCU is a developer tool, so I am
> OK with it not being set by default in Rawhide.  Or have you seen good
> value from (say) PROVE_LOCKING in Rawhide?
> 

Hi Paul,

I'm fine with this, we try to enable debug options in rawhide in order
to get the most out of bug reports/dmesgs that we can. We've definitely
spotted a lot of lockdep reports by having it enabled for general
desktop use cases (but as debugging has become more intensive, the perf
loss from having it enabled is more costly.)

I suspect we'll be OK with PROVE_RCU off though.

Thanks!

regards, Kyle

Re: CONFIG_PROVE_RCU breaks proprietary modules (rcu_lock_map)

[Paul E. McKenney]

On Mon, Jun 21, 2010 at 06:14:26AM -0400, Kyle McMartin wrote:
> On Sun, Jun 20, 2010 at 08:16:05AM -0700, Paul E. McKenney wrote:
> > My kneejerk reaction is that PROVE_RCU is a developer tool, so I am
> > OK with it not being set by default in Rawhide.  Or have you seen good
> > value from (say) PROVE_LOCKING in Rawhide?
> 
> Hi Paul,
> 
> I'm fine with this, we try to enable debug options in rawhide in order
> to get the most out of bug reports/dmesgs that we can. We've definitely
> spotted a lot of lockdep reports by having it enabled for general
> desktop use cases (but as debugging has become more intensive, the perf
> loss from having it enabled is more costly.)
> 
> I suspect we'll be OK with PROVE_RCU off though.

Sounds good -- but please feel free to bug me about this again if it turns
out that you are seeing too many testing escapes from Rawhide into RHEL.
Until then, my thought is that PROVE_RCU testing should primarily be done
by developers on development trees.

							Thanx, Paul