Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
On Mon, Feb 12, 2007 at 01:46:04PM -0500, Derrick J Brashear wrote: > It's being tracked at 53441 in RT, incidentally. Thanks! That helps. Jack > > On Mon, 12 Feb 2007, Derrick J Brashear wrote: > > >On Mon, 12 Feb 2007, Jack Neely wrote: > > > >>>No, but with the new AC_TRY_KBUILD test, we should be able to reliably > >>>determine at build time whether tasklist_lock is exported -- or at least, > >>>whether a weak reference will cause the build to fail. > >> > >>Jeff, is there a patch I can try the AC_TRY_KBUILD test with the > >>1.4.3 RCs? Pointer into CVS? I really need to work on some RHEL5-ish > >>stuff for work. :-) > > > >I'm not Jeff, but, there is such a test, and it doesn't work correctly yet. > > > > > >___ > >OpenAFS-info mailing list > >OpenAFS-info@openafs.org > >https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Jack Neely <[EMAIL PROTECTED]> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
It's being tracked at 53441 in RT, incidentally. On Mon, 12 Feb 2007, Derrick J Brashear wrote: On Mon, 12 Feb 2007, Jack Neely wrote: No, but with the new AC_TRY_KBUILD test, we should be able to reliably determine at build time whether tasklist_lock is exported -- or at least, whether a weak reference will cause the build to fail. Jeff, is there a patch I can try the AC_TRY_KBUILD test with the 1.4.3 RCs? Pointer into CVS? I really need to work on some RHEL5-ish stuff for work. :-) I'm not Jeff, but, there is such a test, and it doesn't work correctly yet. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
On Mon, 12 Feb 2007, Jack Neely wrote: No, but with the new AC_TRY_KBUILD test, we should be able to reliably determine at build time whether tasklist_lock is exported -- or at least, whether a weak reference will cause the build to fail. Jeff, is there a patch I can try the AC_TRY_KBUILD test with the 1.4.3 RCs? Pointer into CVS? I really need to work on some RHEL5-ish stuff for work. :-) I'm not Jeff, but, there is such a test, and it doesn't work correctly yet. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
On Wed, Jan 31, 2007 at 11:43:51AM -0500, Jeffrey Hutzelman wrote: > > > On Tuesday, January 23, 2007 02:14:55 PM -0500 Derrick J Brashear > <[EMAIL PROTECTED]> wrote: > > >On Tue, 23 Jan 2007, Rainer Laatsch wrote: > > > >>I circumvented the MODPOST issue by patching > >>/usr/src/kernels/2.6.18-1.2747.el5-i686/scripts/mod/modpost.c > >>around line 1103 ; replacing 'fatal' by 'warn' > > > >We can't reasonably do that. The problem is the loose binding isn't loose > >enough for this check. > > No, but with the new AC_TRY_KBUILD test, we should be able to reliably > determine at build time whether tasklist_lock is exported -- or at least, > whether a weak reference will cause the build to fail. Jeff, is there a patch I can try the AC_TRY_KBUILD test with the 1.4.3 RCs? Pointer into CVS? I really need to work on some RHEL5-ish stuff for work. :-) Thanks! Jack -- Jack Neely <[EMAIL PROTECTED]> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
On Tuesday, January 23, 2007 02:14:55 PM -0500 Derrick J Brashear <[EMAIL PROTECTED]> wrote: On Tue, 23 Jan 2007, Rainer Laatsch wrote: I circumvented the MODPOST issue by patching /usr/src/kernels/2.6.18-1.2747.el5-i686/scripts/mod/modpost.c around line 1103 ; replacing 'fatal' by 'warn' We can't reasonably do that. The problem is the loose binding isn't loose enough for this check. No, but with the new AC_TRY_KBUILD test, we should be able to reliably determine at build time whether tasklist_lock is exported -- or at least, whether a weak reference will cause the build to fail. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
On Tue, 23 Jan 2007, Rainer Laatsch wrote: I circumvented the MODPOST issue by patching /usr/src/kernels/2.6.18-1.2747.el5-i686/scripts/mod/modpost.c around line 1103 ; replacing 'fatal' by 'warn' We can't reasonably do that. The problem is the loose binding isn't loose enough for this check. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
I circumvented the MODPOST issue by patching
/usr/src/kernels/2.6.18-1.2747.el5-i686/scripts/mod/modpost.c
around line 1103 ; replacing 'fatal' by 'warn'
static void check_for_gpl_usage(enum export exp, const char *m, const char
*s)
{
const char *e = is_vmlinux(m) ?"":".ko";
switch (exp) {
case export_gpl:
/* fatal("modpost: GPL-incompatible module %s%s " */
warn ("modpost: GPL-incompatible module %s%s "
"uses GPL-only symbol '%s'\n", m, e, s);
break;
case export_unused_gpl:
/* fatal("modpost: GPL-incompatible module %s%s " */
warn ("modpost: GPL-incompatible module %s%s "
"uses GPL-only symbol marked UNUSED '%s'\n", m, e,
s);
break;
Best regards / Mit freundlichem Gruss
Rainer Laatsch
__
E-mail: [EMAIL PROTECTED] Universitaet zu Koeln
Reg. Rechenzentrum (ZAIK/RRZK)
Fax : +49 221 478-5590Robert-Koch-Str. 10
Tel : +49 221 478-5582D-50931 Koeln
On Tue, 23 Jan 2007, Jack Neely wrote:
> Folks,
>
> I still see this bug with OpenAFS 1.4.3rc1 on RHEL5 Beta 2
> (2.6.18-1.2747.el5)
>
> Derek, was there a patch that I can test out your suggestion?
>
> LD [M]
> /home/slack/RPM/BUILD/openafs-kmod-1.4.3/_kmod_build_/src/libafs/MODLOAD-2.6.18-1.2747.el5-MP/libafs.o
> Building modules, stage 2.
> MODPOST
> FATAL: modpost: GPL-incompatible module libafs.ko uses GPL-only symbol
> 'tasklist_lock'
>
> Jack Neely
>
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
Folks, I still see this bug with OpenAFS 1.4.3rc1 on RHEL5 Beta 2 (2.6.18-1.2747.el5) Derek, was there a patch that I can test out your suggestion? LD [M] /home/slack/RPM/BUILD/openafs-kmod-1.4.3/_kmod_build_/src/libafs/MODLOAD-2.6.18-1.2747.el5-MP/libafs.o Building modules, stage 2. MODPOST FATAL: modpost: GPL-incompatible module libafs.ko uses GPL-only symbol 'tasklist_lock' Jack Neely -- Jack Neely <[EMAIL PROTECTED]> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes: > On Tuesday, November 21, 2006 04:16:51 PM +0100 Stephan Wiesand > <[EMAIL PROTECTED]> wrote: > >> But isn't loading such a module supposed to fail? Is it only in this >> special case that it doesn't, because of the "weak" definition of >> tasklist_lock in the AFS module and/or because of the fallback to >> rcu_read_lock? > > It is, except that our reference is weak, so we can detect at runtime > whether the symbol is available to us. The kernel handles this case > correctly; if a non-GPL module has a weak reference to a GPL-only symbol, > the reference will be left unresolved, just as if the symbol were not > present at all. One way to solve this is to make a compile-time check for the symbol and if it fails there then we don't run the runtime check, we ifdef it out. That way the build wont fail in modpost. > -- Jeff -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: 1.4.2 client on RHEL5 beta 2
On Tuesday, November 21, 2006 04:16:51 PM +0100 Stephan Wiesand <[EMAIL PROTECTED]> wrote: But isn't loading such a module supposed to fail? Is it only in this special case that it doesn't, because of the "weak" definition of tasklist_lock in the AFS module and/or because of the fallback to rcu_read_lock? It is, except that our reference is weak, so we can detect at runtime whether the symbol is available to us. The kernel handles this case correctly; if a non-GPL module has a weak reference to a GPL-only symbol, the reference will be left unresolved, just as if the symbol were not present at all. -- Jeff ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
