[OpenAFS-devel] Re: linux 2.6.x module version magic failure on SMP systems (FC2)

Jeffrey Hutzelman jhutz@cmu.edu
Fri, 18 Jun 2004 19:55:30 -0400


On Friday, June 18, 2004 19:32:16 -0400 "chas williams (contractor)" 
<chas@cmf.nrl.navy.mil> wrote:

> In message <20040618201047.GA22511@jadzia.bu.edu>,Matthew Miller writes:
>>> Is the SMP kernel compiled with CONFIG_REGPARM?
>>> Are you using the patches from Rainer?
>>
>> Yes and yes. :)
>
> for the record i am running 2.6.7-rc2 on a 2-proc SMP system but
> i dont use CONFIG_REGPARM.  it seems pretty likely that this
> is part of your problem.  you might need to make sure the your
> libafs is being built with the same gcc as the kernel

> (this should be fixed with the new build scheme from jeff).

You'd think.  But he's already seen the mismatched-vermagic error, and the 
standard fix for that only works if you have my build system (otherwise you 
go from mismatched vermagic to no vermagic).

Based on the patches Rainer has already sent on the REGPARM issue, my 
understanding is that the problem is at least in part a failure on our part 
to actually have argument types match between definitions and references of 
our own functions.  Now, why this only matters with CONFIG_REGPARM I don't 
know.


Still, I'd like to know if rebuilding the kernel without CONFIG_REGPARM 
(and then rebuilding the AFS module as well) fixes the problem for Matthew. 
I know that's not an optimal solution, but at least it will confirm that's 
where we should be looking for problems.


> osi_Init() should probably do the following to create
> the anonymous cred instead of inheriting current. comments?
>
> Index: src/afs/afs_osi.c
> ===================================================================
> RCS file: /cvs/openafs/src/afs/afs_osi.c,v
> retrieving revision 1.44
> diff -u -u -r1.44 afs_osi.c
> --- src/afs/afs_osi.c	21 Apr 2004 02:20:21 -0000	1.44
> +++ src/afs/afs_osi.c	18 Jun 2004 17:58:54 -0000
> @@ -74,13 +74,14 @@
>  #endif /* AFS_HPUX_ENV */
>
>      if (!afs_osicred_initialized) {
> -#if defined(AFS_LINUX26_ENV)
> -	afs_osi_credp = crref();
> -#elif defined(AFS_XBSD_ENV)
> +#if defined(AFS_XBSD_ENV)
>  	/* Can't just invent one, must use crget() because of mutex */
>  	afs_osi_credp = crdup(osi_curcred());
>  #else
>  	memset(&afs_osi_cred, 0, sizeof(struct AFS_UCRED));
> +#if defined(AFS_LINUX26_ENV)
> +        afs_osi_cred.cr_group_info = groups_alloc(0);
> +#endif
>  	crhold(&afs_osi_cred);	/* don't let it evaporate */
>  	afs_osi_credp = &afs_osi_cred;
>  #endif

I'm not sure why we inherit from current in the osi_Init() case, but I 
can't see any good reason for it.  Perhaps someone thought it was too hard 
to call groups_alloc(0) in another place.  Wait...  didn't you write the 
AFS_LINUX26_ENV case to begin with?

Just calling groups_alloc(0) seems fine to me.  We don't need current's 
groups.

-- Jeff